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Abstract 

Recent  years  have  seen  a  massive  increase  in  illegal,  suspicious,  and  malicious 
traffic  traversing  government  and  military  computer  networks.  Some  examples  include 
illegal  file  distribution  and  disclosure  of  sensitive  information  using  the  Bit  Torrent  hie 
sharing  protocol,  criminals  and  terrorists  using  Voice  over  Internet  Protocol  (VoIP) 
technologies  to  communicate,  and  foreign  entities  exhitrating  sensitive  data  from  gov¬ 
ernment,  military,  and  Department  of  Defense  contractor  networks. 

As  a  result  of  these  growing  threats,  the  TRacking  and  Analysis  for  Peer-to- 
Peer  (TRAPP)  system  was  developed  in  2008  to  detect  Bit  Torrent  and  VoIP  traffic  of 
interest.  The  TRAPP  system,  designed  on  a  Xilinx  Virtex-II  Pro  Field  Programmable 
Gate  Array  (FPGA)  proved  valuable  and  ehective  in  detecting  traffic  of  interest  on 
a  100  Mbps  network.  Using  concepts  and  technology  developed  for  the  TRAPP 
system,  the  TRAPP-2  system  is  developed  on  a  Xilinx  ML510  FPGA.  The  goals  of 
this  research  are  to  evaluate  the  performance  of  the  TRAPP-2  system  as  a  solution 
to  detect  and  track  malicious  packets  traversing  a  gigabit  Ethernet  network.  The 
TRAPP-2  system  detects  a  Bit  Torrent,  Session  Initiation  Protocol  (SIP),  or  Domain 
Name  System  (DNS)  packet,  extracts  the  payload,  compares  the  data  against  a  hash 
list,  and  if  the  packet  is  suspicious,  logs  the  entire  packet  for  future  analysis. 

Results  show  that  the  TRAPP-2  system  captures  95.56%  of  Bit  Torrent,  20.78% 
of  SIP  INVITE,  37.11%  of  SIP  BYE,  and  91.89%  of  DNS  packets  of  interest  while  un¬ 
der  a  93.7%  network  utilization  (937  Mbps).  For  another  experiment,  the  contraband 
hash  list  size  is  increased  from  1,000  to  131,072,000  unique  items.  The  experiment 
reveals  that  each  doubling  of  the  hash  list  size  results  in  a  mean  increase  of  approx¬ 
imately  16  central  processing  unit  cycles.  These  results  demonstrate  the  TRAPP-2 
system’s  ability  to  detect  traffic  of  interest  under  a  saturated  network  utilization  while 
maintaining  large  contraband  hash  lists. 
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Performance  Evaluation  of  a  Field  Programmable 
Gate  Array-Based  System  for  Detecting  and  Tracking 
Peer-to-Peer  Protocols  on  a  Gigabit  Ethernet  Network 

I.  Introduction 

1.1  Motivation 

Billions  of  packets  traverse  government  and  military  networks  every  day.  Often, 
these  packets  have  legitimate  destinations.  Unfortunately,  the  past  few  years 
have  seen  a  massive  increase  in  illegal,  suspicious,  and  malicious  traffic.  Some  exam¬ 
ples  include  Bit  Torrent  illegal  file  distribution,  suspects  of  interest  using  Voice  over  In¬ 
ternet  Protocol  (VoIP)  phones  to  conduct  business,  and  Domain  Name  System  (DNS) 
data  exfiltration.  Recent  stories  include  blueprints  for  Marine  One  being  leaked  by 
a  United  States  contractor  using  a  Bit  Torrent  file  sharing  program,  the  Mumbai  ter¬ 
rorists  using  VoIP  phones  to  communicate,  and  Chinese  hackers  pilfering  intellectual 
property  from  Google  and  other  United  States  companies  [FOX09]  [KahOS]  [WirlO]. 

As  a  result  of  these  growing  threats,  the  TRacking  and  Analysis  for  Peer-to- 
Peer  (TRAPP)  system  was  developed  to  detect  Bit  Torrent  and  VoIP  traffic  of  inter¬ 
est  [Sch09].  The  system  resides  on  a  Xilinx  Virtex-II  Pro  Field  Programmable  Gate 
Array  (FPGA).  The  first  iteration  prototype  is  limited  in  both  processing  speed  and 
by  a  100  megabit  Ethernet  card,  but  still  captures  packets  of  interest  with  a  “prob¬ 
ability  of  intercept  of  at  least  99.0%,  using  a  95%  confidence  interval  and  given  an 
89.6  Mbps  network  utilization”  [Sch09].  These  results  prove  the  TRAPP  system  is  a 
viable  tool  worth  expanding  its  capabilities  to  detect  malicious  network  traffic. 

1.2  Overview  and  Goals 

This  research  extends  the  technology  and  concepts  of  the  first  TRAPP  system  by 
implementing  a  more  powerful  FPGA  and  incorporating  an  additional  protocol.  The 
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focus  of  this  research  is  create  a  second  generation  TRAPP  system,  named  TRAPP-2, 
that  is  designed  on  a  Xilinx  ML510  FPGA  board  with  a  faster  processor  and  a  gigabit 
Ethernet  controller  [Xil09].  The  original  TRAPP  system  detects  the  Bit  Torrent  and 
Session  Initiation  Protocol  (SIP)  peer-to-peer  protocols  in  real-time.  For  the  TRAPP- 
2  system,  malicious  Domain  Name  System  (DNS)  detection  is  added.  Ultimately,  the 
research  determines  that  the  TRAPP-2  system  is  a  feasible  solution  to  detect  and 
track  protocols  of  interest  for  law  enforcement  and  intelligence  agencies  on  gigabit 
Ethernet  networks. 

The  TRAPP-2  system  meets  four  measurement  goals.  The  first  goal  determines 
the  packet  processing  times  for  packets  detected  by  the  TRAPP-2  system.  The  second 
goal  determines  the  probability  of  packet  intercept  under  a  flood  of  packet-of-interest 
traffic.  The  third  goal  determines  the  probability  of  packet  intercept  under  various 
network  utilizations.  The  last  goal  determines  how  increasing  the  hash  list  size  affects 
the  packet  processing  time.  The  two  metrics  used  to  measure  performance  are  packet 
processing  time,  measured  in  Central  Processing  Unit  (CPU)  cycles,  and  probability 
of  packet  intercept. 

1.3  Thesis  Layout 

Chapter  1  outlines  the  motivation,  overview,  and  goals  of  the  research.  An 
overview,  background  information,  and  related  research  on  illicit  traffic,  network  traf¬ 
fic  classification,  network  traffic  obfuscation  methods,  current  methods  of  detecting 
malicious  and  illegal  network  traffic,  the  Substitute  Database  Manager  (sdbm)  hash¬ 
ing  function,  and  the  TRAPP  system  are  covered  in  Chapter  2.  Chapter  3  explains  the 
method  and  experiments  used  to  evaluate  the  performance  of  the  TRAPP-2  system. 
Chapter  4  presents  the  analysis  and  discussion  of  the  results  from  the  experiments. 
The  conclusions  drawn  from  the  research,  real-world  significance,  and  future  research 
areas  are  detailed  in  Chapter  5.  Appendix  A  contains  all  of  the  experimental  data. 
Appendix  B  contains  the  pilot  test  data  used  to  design  and  build  the  TRAPP-2  sys- 
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tern.  Appendix  C  provides  a  hardware  construction  guide  to  build  the  TRAPP-2 
system. 
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II.  Literature  Review 


This  chapter  presents  an  overview,  background  information,  and  related  research 
on  illicit  traffic,  network  traffic  classification,  network  traffic  obfuscation  meth¬ 
ods,  current  methods  of  detecting  malicious  and  illegal  network  traffic,  the  Substitute 
Database  Manager  (sdbm)  hashing  function,  and  the  TRacking  and  Analysis  for  Peer- 
to-Peer  (TRAPP)  system.  Section  2.1  provides  a  brief  overview  of  the  BitTorrent, 
Voice  over  Internet  Protocol  (VoIP),  and  Domain  Name  System  (DNS)  protocols  and 
their  illegitimate  uses.  The  methods  of  classifying  network  traffic  are  detailed  in  Sec¬ 
tion  2.2.  Section  2.3  covers  some  of  the  obfuscation  and  evasion  methods  used  to 
hide  network  traffic  and  data.  This  allows  for  an  exploration  of  the  current  methods 
of  detecting  illicit  traffic  in  Section  2.4.  This  is  followed  by  an  examination  of  the 
sdbm  hashing  function  in  Section  2.5  and  the  current  TRAPP  system’s  capabilities 
and  limitations  in  Section  2.6.  The  chapter  is  summarized  in  Section  2.7. 

2.1  Illicit  Traffic 

The  Internet  has  evolved  from  a  small  network  of  sparsely  connected  computers 
to  an  expansive  web  of  millions.  The  rapid  access  to  information,  knowledge,  and 
current  events  has  been  paralleled  with  a  proliferation  of  illicit  data  and  traffic.  Bit- 
Torrent,  VoIP,  and  DNS  are  legitimate  protocols  and  services;  however,  they  can  also 
be  used  for  illicit  purposes.  Some  examples  include  the  distribution  of  illegal  files  us¬ 
ing  BitTorrent,  terrorists  using  VoIP  for  command  and  control  during  operations,  and 
hackers  exploiting  DNS  to  exfiltrate  sensitive  data  from  networks  [KahOS]  [Van09]. 

2.1.1  The  BitTorrent  Protocol.  The  BitTorrent  protocol  is  the  natural 
evolution  of  file  sharing  protocols  [CohOS].  The  BitTorrent  protocol  was  created  by 
Bram  Cohen  as  an  alternative  to  the  centralized  file  sharing  programs  such  as  Napster 
and  Gnutella  [CohOS]. 

The  Napster  file  sharing  program  was  created  by  Shawn  Fanning  to  allow  his 
friends  to  share  and  distribute  .mp3  music  files  [TysOSj.  The  popularity  of  Napster 
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exploded  and  became  the  preferred  method  of  sharing  legal  and  illegal  music  hies 
over  the  Internet.  The  Napster  system  relied  on  a  central  server,  run  by  the  Napster 
organization,  to  point  clients  to  the  specihc  .mp3  music  hies  requested.  The  server 
acted  as  a  mediator  to  set  up  the  direct  peer-to-peer  connection  between  the  hie 
downloader  and  the  hie  uploader.  The  servers  did  not  store  or  host  any  of  the  actual 
.mp3  hies  being  downloaded.  It  did  not  take  long  for  record  companies  and  prosecutors 
to  target  Napster  for  the  dissemination  of  copyrighted  music.  The  central  servers  that 
the  Napster  system  relied  on  proved  to  be  an  easy  target  for  the  Recording  Industry 
Association  of  America  and  various  music  labels.  Ultimately,  the  lawsuits  forced 
Napster  to  shut  down  in  2001  [Fel04]. 

As  a  result  of  the  Napster  shutdown,  hie  sharing  programs  migrated  toward  a 
decentralized  approach.  This  eliminated  the  need  for  a  centralized  server  and  led  to 
the  development  of  Bit  Torrent  [CohOS].  In  addition  to  a  decentralized  architecture, 
the  BitTorrent  protocol  implemented  two  new  methods  of  downloading  hies.  The  hrst 
method  was  to  break  the  hie  into  blocks  of  256  kilobytes.  This  allowed  downloaders 
to  accumulate  diherent  blocks,  or  parts  of  the  hie,  and  assemble  them  upon  download 
completion  to  create  the  entire  hie.  As  soon  as  a  block  was  completely  downloaded, 
it  was  immediately  uploaded  to  other  peers  seeking  the  hie.  To  aid  in  the  speed 
of  downloading,  the  BitTorrent  protocol  was  designed  to  capitalize  on  the  disparate 
download  versus  upload  speeds  ohered  by  Internet  Service  Providers  (ISPs).  The 
downloader  of  a  hie  was  able  to  simultaneously  download  blocks  of  the  hie  from 
diherent  uploaders.  Since  ISPs  provided  download  speeds  signihcantly  greater  than 
upload  speeds,  a  downloader  could  accumulate  numerous  smaller  peer  upload  speeds 
to  match  his  download  speed  [CohOS].  Over  time,  the  BitTorrent  protocol  has  become 
the  preferred  method  of  sharing  hies  over  the  Internet  due  to  its  efficiency. 

Currently,  the  BitTorrent  protocol  consists  of  two  diherent  protocols.  The  hrst 
is  the  BitTorrent  Tracker  protocol  which  runs  over  the  Hypertext  Transfer  Protocol 
(HTTP).  It  communicates  between  clients  and  a  tracker  website  to  point  clients  to 
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the  peers  sharing  the  requested  hie.  A  tracker  website  maintains  a  dynamic  database 
of  peers  associated  with  a  hie  [Coh08] . 

The  second,  and  more  relevant  protocol  for  this  research,  is  the  peer  wire  pro¬ 
tocol.  The  peer  wire  protocol  runs  over  the  Transmission  Control  Protocol  (TCP) 
and  is  used  to  exchange  the  hie  pieces  specihed  in  the  hle’s  .torrent  hie.  The  peer 
wire  protocol  relies  on  the  Secure  Hash  Algorithm  1  (SHA-1)  for  hie  identihcation 
and  data  block  integrity  verihcation  [Coh08].  SHA-1,  outlined  in  Request  for  Com¬ 
ments  (RFC)  3174,  is  a  United  States  Government  algorithm  formally  named  as  the 
Federal  Information  Processing  Standards  Publication  180-1  (FIPS  180-1)  [RFCOl]. 
The  algorithm  is  designed  to  take  a  variable-sized  binary  input  less  than  2®^  bits  and 
output  a  160  bit  message  called  a  “message  digest.” 

The  SHA-1  hash  function  is  used  to  hash  the  information  dictionary  found  in 
the  .torrent  hie.  The  digest  represents  a  digital  signature  of  the  hie  and  its  contents  to 
prevent  confusing  diherent  hies  with  the  same  hie  name.  According  to  the  Bit  Torrent 
Protocol  Specihcations,  “The  peer  wire’s  protocol  consists  of  a  handshake  followed 
by  a  never-ending  stream  of  length-prehxed  messages.  The  handshake  starts  with 
character  nineteen  (decimal)  followed  by  the  string  BitTorrent  protocol”  [Coh08]. 
The  decimal  nineteen  followed  by  the  string  BitTorrent  protocol  is  critical  for 
identifying  BitTorrent  packets  in  this  research.  The  next  piece  of  information  is  the 
20  byte  SHA-1  hash  of  the  information  dictionary  [Coh08].  An  example  of  a  handshake 
message  is  dissected  below  [Sch09]. 

The  client  sends  handshakes  to  other  peers  to  retrieve  parts  of  the  hie: 

<13>BitTorrent  protocol<0000000000100001101C9D63211C3C570FFBA 

DD49C5649D3FB4972732D5554313737302DF39FFDC774B56A4C5352C11C> 
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Line  breaks  and  spaces  are  added  to  aid  in  readability: 


<13>BitTorrent  protocol 

<00  00  00  00  00  10  00  01 

10  1C  9D  63  21  1C  3C  57  OF  FB  AD  D4  9C  56  49  D3  FB  49  72  73 

2D  55  54  31  37  37  30  2D  F3  9F  FD  C7  74  B5  6A  4C  53  52  Cl  1C> 

The  first  piece  of  information  in  the  extracted  handshake  is  the  string  length 
of  the  protocol  being  used  (0x13  in  hexadecimal  is  19  in  decimal.)  The  second 
piece  is  the  protocol  header,  the  ASCII  string  “BitTorrent  protocol”  which  is  19 
characters  in  length.  The  third  portion  consists  of  the  reserved  extension  bytes 
00  00  00  00  00  10  00  01.  This  is  followed  by  the  SHA-1  hash  of  the  information 
dictionary: 

10  1C  9D  63  21  1C  3C  57  OF  FB  AD  D4  9C  56  49  D3  FB  49  72  73 
and  hnally  the  Peer  Identihcation: 

2D  55  54  31  37  37  30  2D  F3  9F  FD  C7  74  B5  6A  4C  53  52  Cl  1C 

The  BitTorrent  protocol  relies  on  the  transfer  of  blocks  of  data  that  combine  to 
form  the  hie  being  shared.  As  a  result,  these  blocks  are  also  run  through  SHA-1  to 
ensure  data  integrity.  The  client  performs  a  SHA-1  on  each  downloaded  block  and 
compares  it  to  the  value  in  the  .torrent  hie  to  verify  the  data  integrity  [CohOS]. 

2.1.2  The  Voice  over  Internet  Protocol.  The  Voice  over  Internet  Protocol 
(VoIP)  is  primarily  used  to  make  phone  calls  over  the  Internet  [Sky09].  A  person’s 
voice  is  digitized,  placed  in  a  packet,  and  sent  to  the  receiver  on  the  other  end.  The 
primary  protocol  used  to  setup,  maintain,  and  tear  down  a  VoIP  call  is  the  Session 
Initiation  Protocol. 

2. 1.2.1  The  Session  Initiation  Protocol.  The  plan  and  protocol  for  the 
Session  Initiation  Protocol  (SIP)  was  submitted  by  Henning  Schulzrinne  of  Columbia 
University  in  1999  [UbiOS].  The  protocol,  approved  by  the  Internet  Engineering 


7 


Task  Force  (IETF)  as  Request  for  Comments  (RFC)  2543,  centered  on  establish¬ 
ing  and  controlling  multiparty  multimedia  sessions  [UbiOS].  The  SIP  protocol  was 
updated  in  IETF  RFC  3261  and  dehned  to  be  an  application-layer  control  protocol 
that  can  establish,  modify,  and  terminate  multimedia  sessions  such  as  Internet  tele¬ 
phony  calls  [RFC02].  The  purpose  of  SIP  is  to  assist  in  peer  location  in  addition 
to  managing  the  connection  once  it  is  established.  Applications  such  as  interactive 
gaming,  media  on  demand,  and  voice,  video,  or  web  conferencing  utilize  the  SIP  pro¬ 
tocol  [UbiOS] .  More  importantly,  SIP  is  currently  used  by  VoIP  providers  Vonage  and 
Skype  [Cis02]  [SkyOOj. 

2. 1.2. 2  VoIP  Technical  Specifications.  Figure  2.1  is  an  illustration 
of  how  a  VoIP  call  is  made  using  SIP.  For  clarihcation,  Alice  is  calling  Bob  using  a 
Proxy  Server  that  coordinates  and  routes  requests  between  clients  and  servers.  The 
call  also  uses  a  Registrar/Location  Server,  which  is  a  database  of  all  the  SIP  clients 
and  SIP  contact  information  within  a  network  domain.  Lastly,  BYE  and  INVITE  are 
SIP  specihc  request  messages. 

•  Alice’s  SIP  client  sends  an  INVITE  request  to  her  Proxy  Server  (1).  Alice’s 
Proxy  Server  notihes  her  that  a  call  is  being  attempted  (2).  Alice’s  Domain 
Name  System  (DNS)  server  must  perform  a  DNS  lookup  to  determine  the  In¬ 
ternet  Protocol  (IP)  address  of  Bob’s  domain  (3,4). 

•  Alice’s  Proxy  Server  sends  the  INVITE  request  to  Bob’s  Proxy  Server  (5).  Bob’s 
Proxy  Server  notihes  Alice’s  Proxy  Server  that  a  call  is  being  attempted  (6). 
Bob’s  Proxy  Server  must  query  the  Registrar/Location  Server  to  determine 
Bob’s  exact  location  and  if  he  is  currently  signed  on  (7,8).  Bob’s  Proxy  Server 
forwards  the  INVITE  message  to  Bob’s  SIP  client  (9). 

•  Bob  sends  his  ringing  response  back  to  Alice  via  the  Proxy  Servers  (10,11,12). 
If  Bob  is  available,  his  SIP  client  sends  an  OK  response  to  Alice  via  the  Proxy 
Servers  (13,14,15). 


•  Alice  receives  Bob’s  OK  and  sends  an  acknowledgment  directly  back  to  Bob  to 
confirm  the  call  (16).  The  session  is  now  established  and  data  can  be  exchanged 
via  the  Real-time  Transport  Protocol  [CislO]. 


DNS  “"I  I  Location 

Server  I  I  Service 


Figure  2.1:  The  Session  Initiation  Protocol  Process  [CislO]. 

The  steps  of  interest  are  at  the  beginning  and  end  of  the  SIP-based  VoIP  call, 
particularly  the  session  setup  and  tear  down.  During  the  setup  of  a  SIP-based  VoIP 
call,  the  INVITE  request  is  used  to  initiate  a  connection  from  one  client  to  another. 
The  INVITE  request  contains  the  SIP  Uniform  Resource  Identiher  (URI).  The  URI  is 
the  address  of  the  client  on  the  network  and  follows  the  same  formatting  convention  as 
an  email  address  (userShost).  In  the  SIP  message,  the  SIP  URI  is  concatenated  to  the 
sip:  identiher.  Examples  include  sip:bob@example  .  com  and  sip : 2001010 . 1 . 1 . 1. 
During  the  tear  down  of  a  SIP-based  VoIP  call,  the  BYE  request  messages  are  used  to 
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terminate  a  SIP  connection  session.  The  BYE  message  also  contains  SIP  URIs,  which 
can  identify  certain  users  or  domain  addresses.  For  the  purpose  of  this  research,  the 
INVITE  and  BYE  SIP  requests  are  examined  in  the  SIP  transaction  because  they 
contain  the  URI  of  both  the  sender  and  receiver. 

2.1.3  The  Domain  Name  System.  The  Domain  Name  System  (DNS)  is 
perhaps  the  most  critical  service  for  the  Internet.  DNS  converts  human-friendly  host 
addresses  to  computer  readable  Internet  host  addresses,  much  like  a  phone  book.  This 
allows  a  user  to  remember  google .  com  instead  of  the  IP  address  74 . 125 . 67 . 100.  De¬ 
spite  the  massive  dependency  on  DNS,  the  security  and  vulnerabilities  of  the  protocol 
have  recently  come  to  light.  A  brief  overview  of  how  DNS  works  is  followed  by  the 
current  methods  of  abusing  the  protocol,  specihcally  DNS  tunneling. 

2. 1.3.1  The  Domain  Name  System  Overview.  DNS  is  a  distributed 
database  that  is  indexed  by  domain  names  with  the  goal  of  decentralized  adminis¬ 
tration.  The  domain  name  is  part  of  a  path  in  an  inverted  tree  that  constitutes  the 
domain  name  space.  As  shown  in  Figure  2.2,  the  top  of  the  inverted  tree  contains  the 
root,  with  various  subdomains  that  branch  off  from  it  [ALOl]. 
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Each  of  the  nodes,  or  domain  names,  contain  a  text  label  that  is  capped  at  63 
characters  in  length  as  opposed  to  the  root  which  is  a  zero-length,  or  null,  label.  The 
full  domain  name  of  a  node  starts  from  the  node  and  follows  the  path  up  towards  root, 
adding  each  subsequent  node  to  its  name  [ALOl].  In  the  example  from  Figure  2.2, 
this  would  be  www .  cs  .  Colorado  .  edu. 

2. 1.3. 2  Domain  Name  System  and  the  Internet.  DNS  is  implemented 
on  the  Internet  to  create  one  of  the  most  crucial  infrastructure  services.  The  Internet 
domain  name  space  consists  of  certain  top  level  domains.  Some  of  these  top  level 
domains  include  .com,  .edu,  .mil,  and  .gov  and  are  managed  by  the  Internet  Corpo¬ 
ration  for  Assigned  Names  and  Numbers  (ICANN).  With  the  knowledge  of  the  top 
level  domains,  it  is  easier  to  dissect  and  read  domain  names.  The  decentralized  ad¬ 
ministration  of  DNS  is  possible  through  delegation.  Delegation  allows  domains  and 
subdomains  to  be  broken  up  for  ease  of  management  [ALOl].  The  personnel  who 
run  the  .mil  domain  would  rather  delegate  responsibility  to  the  subdomains,  such  as 
af  .mil  and  navy.mil,  than  manage  each  of  them. 

A  key  component  of  a  domain  name  space  is  the  name  server.  Name  servers 
contain  information  pertaining  to  the  domain  name  space,  also  called  a  zone.  There 
are  two  types  of  name  servers:  secondary  master  and  primary  master.  The  secondary 
master  for  a  zone  name  server  polls  the  primary  master  server  for  zone  data.  The 
primary  master  name  server  for  a  zone  extracts  the  data  for  the  zone  from  a  local  hie, 
called  zone  data  hies,  which  are  also  referred  to  as  data  hies  or  database  hies.  The  zone 
data  hies  contain  resource  records  describing  the  hosts  and  delegation  subdomains  in 
the  zone.  These  zone  data  hies  also  contain  entries  called  DNS  resource  records  [ALOl]. 

Each  of  the  domains  in  a  domain  name  space  contains  resource  records  that 
contain  data  associated  with  the  domain.  Some  of  these  records  include  A  for  address 
record,  NS  for  nameserver  record,  CNAME  for  canonical  name  record,  and  TXT  for 
text  record  [ALOl]. 
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Another  key  component  of  the  domain  name  space  is  the  resolver,  which  is 
a  client  that  accesses  name  servers  when  information  is  needed.  An  example  is  a 
web  browser  trying  to  determine  the  IP  address  of  google .  com.  The  resolver’s  three 
tasks  are  to  handle  querying  a  name  server,  interpreting  responses,  and  passing  the 
information  to  the  requesting  program  [ALOl]. 

The  resolution  process  is  important  for  name  servers  to  retrieve  data  from  the 
domain  name  space  for  the  resolvers.  Name  servers  perform  two  functions  in  the 
domain  name  space.  The  hrst  is  to  resolve  data  within  their  own  authoritative  zones 
(within  their  own  organization’s  network).  The  second  function  is  resolve  data  for  non- 
authoritative  zones  in  the  domain  name  space  (from  another  organization’s  network). 
The  resolution  of  data  by  name  servers  is  accomplished  either  recursively  or  iteratively. 
In  the  recursive  case,  name  servers  pass  the  responsibility  to  more  authoritative  name 
servers  to  resolve  data.  The  iterative  process  requires  a  single  name  server  to  query 
other  name  servers  to  try  and  get  closer  to  the  actual  answer  [ALOl]. 

2. 1.3. 3  Abusing  the  Internet  Domain  Name  System.  The  reliability, 
speed,  and  dependence  on  DNS  make  it  a  critical  service  for  the  Internet.  However, 
the  DNS  protocol  can  be  taken  advantage  of  for  nefarious  purposes.  One  method  of 
abusing  the  protocol  is  DNS  tunneling  as  first  suggested  in  a  1998  Bugtraq  posting  by 
Oskar  Pearson  [Pea98].  DNS  tunneling  is  an  abuse  of  DNS  records  to  transfer  non- 
DNS  data  in  and  out  of  a  network  using  the  DNS  protocol.  Non-DNS  data  can  include 
files,  botnet  commands,  and  even  segmented  audio  media  [Van09].  DNS  tunneling  is 
appealing  because  it  is  a  covert  channel  and  is  operating  system  independent  [Van09] . 
DNS  tunneling  contrasts  with  legitimate  tunnels,  such  as  Virtual  Private  Network 
and  Secure  Shell,  which  are  explained  in  Section  2.3. 

The  concept  of  the  DNS  tunnel  is  to  use  a  DNS  server,  under  control  of  a  hacker, 
as  an  external  trusted  server  to  tunnel  information  out  of  a  protected  network  through 
User  Datagram  Protocol  (UDP)  port  53.  Since  most  protected  networks  permit  DNS 
traffic  to  exit,  the  requests  are  granted.  The  data  are  transmitted  through  the  tunnel 


12 


by  sending  data  to  the  hacker’s  DNS  server  in  the  form  of  a  query  and  getting  data 
back  in  the  form  of  a  response  [Van09].  This  can  be  done  once  to  communicate  with 
a  botnet  or  repeated  thousands  of  times  to  exhltrate  hies  and  data.  The  tunneled 
data  appears  as  the  DNS  request,  [exfiltrated  data]  .hacker .  com,  with  the  data 
residing  in  the  lowest  level  domain.  The  [exfiltrated  data]  is  usually  encoded  in 
Base32  or  Base64  and  would  look  more  like  OadbEnPJygrGCgvGS.hacker.com  if  it 
was  viewed  using  a  network  protocol  analyzer  such  as  Wireshark.  Since  hacker .  com 
is  under  the  hacker’s  control,  the  DNS  server  interprets  the  request  according  to 
the  hacker’s  desires.  The  hacker’s  DNS  server  decodes  the  exhitrated  data  and  then 
responds  with  data  that  is  tunneled  back  to  the  compromised  computer  in  the  form 
of  a  DNS  response  [Van09].  Figure  2.3  summarizes  the  process  in  hve  steps: 


© 

rj: 

Victim 


*• 


hacker.com 
DNS  server 


'^^^N^CompanyX 
root  server 


Figure  2.3:  Establishing  a  Domain  Name  System  Tunnel. 


1.  The  victim’s  computer  performs  a  DNS  request  for 
[exfiltrated  data] .hacker.com. 

2.  [exfiltrated  data]  .hacker.com  is  not  locally  cached,  so  the  victim  asks  the 
Company  X  root  DNS  server  if  it  can  resolve  the  request. 

3.  Company  X’s  root  DNS  server  cannot  resolve  the  request,  so  it  forwards  it  to 
the  DNS  server  under  the  hacker’s  control  at  hacker .  com. 
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4.  The  hacker  sends  back  a  DNS  response  which  easily  passes  through  a  network 
defense  appliance  since  DNS  is  assumed  to  be  trusted. 

5.  The  victim  receives  the  DNS  response  to  exhltrate  more  data,  connect  to  a 
botnet,  etc. 

The  amount  and  type  of  data  transferred  through  a  DNS  tunnel  depends  on  the 
DNS  record  being  used.  Some  of  the  commonly  abused  DNS  records  to  tunnel  data 
include: 

•  TXT:  Text  records  permit  free  form  data  and  can  include  spaces.  Information 
stored  is  encoded  in  Base64  allowing  220  bytes  of  data  per  record.  TXT  records 
can  contain  any  data  in  them  as  long  as  the  length  is  less  than  255  octets. 

•  CNAME:  Canonical  Name  Records  are  alias  records.  They  only  allow  the  char¬ 
acters  A  through  Z,  digits  0-9,  and  the  hyphen. 

•  EDNSO:  The  Extension  Mechanism  for  DNS  record  can  be  greater  than  the  512 
byte  UDP  DNS  maximum  and  carry  a  1280  byte  default  payload. 

•  A  and  MX:  Address  and  Mail  records,  respectively.  They  can  be  used  as  well, 
but  have  more  limitations  and  cannot  store  all  types  of  data  [Van09]. 

2. 1.3. 4  The  OzymanDNS  Domain  Name  System  Tunneling  Application. 

OzymanDNS  is  a  tunneling  program  used  to  tunnel  all  Internet  traffic  through  DNS. 
It  accomplishes  this  by  encapsulating  Internet  data  as  DNS  traffic  and  sending  it 
through  UDP  port  53  instead  of  the  traditional  HTTP  TCP  port  80.  It  was  developed 
by  the  DNS  security  guru  Dan  Kaminsky.  This  program  allows  users  to  discreetly 
send  traffic  through  port  53  and  the  DNS  protocol.  Organizations  and  agencies  rely 
on  DNS  to  provide  domain  name  resolution  and  lookups  for  the  network  and  users. 
The  ability  for  malicious  users  to  transport  possible  data  and  traffic  through  a  trusted 
and  overall  innocuous  port  is  a  major  threat.  The  OzymanDNS  suite  of  perl  scripts 
is  32  kilobytes,  making  it  a  small  and  efficient  exhltration  tool  [Kam09]. 
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2. 1.3. 5  The  Iodine  Domain  Name  System  Tunneling  Applieation. 
Iodine  is  another  program  capable  of  tunneling  Internet  Protocol  version  4  traffic 
through  DNS.  Iodine  offers  more  benehts  over  other  DNS  tunnel  implementations. 
Some  of  these  benehts  include  portability  between  systems,  a  Message-Digest  algo¬ 
rithm  5  (MD5)  challenge-response  for  login,  and  the  use  of  the  NULL  type  to  allow 
unencoded  downstream  data  which  allows  up  to  a  kilobyte  of  compressed  payload 
data.  The  single  program  can  operate  as  a  client  or  server  depending  on  the  options 
specihed  by  a  user.  Iodine  supports,  in  decreasing  bandwidth  order,  the  use  of  NULL, 
TXT,  SRV,  MX,  CNAME  and  A  records  [Kry09].  For  this  research,  the  malicious 
DNS  packets  used  for  testing  are  created  using  Iodine. 

2.2  Analyzing  and  Classifying  Network  Traffic 

Before  the  advent  of  Darknets  and  anonymizers  like  Tor  (see  Section  2.3),  ana¬ 
lyzing  network  traffic  was  relatively  simple  [BEPW02]  [Tor09a].  The  three  methods 
for  analyzing  network  traffic  are  port  matching,  payload  analysis,  and  transport-level 
communication  how. 

2.2.1  Port  Matching  Analysis.  The  most  rudimentary,  although  sometimes 
most  ehective,  method  of  classifying  network  traffic  is  done  by  port  matching  analysis. 
The  transport  level  source  and  destination  ports  are  extracted  to  reveal  which  ports 
are  being  used.  By  comparing  the  ports  to  a  known  list  of  protocols,  the  traffic  can 
be  classihed  quickly  and  efficiently. 

Simple  examples  include  the  use  of  port  23  for  telnet  or  port  80  for  web  servers. 
Ports  23  and  80  are  well  known  ports  for  their  respective  services,  although  they  are 
not  bound  to  the  ports.  A  protocol  of  interest  in  this  research,  DNS,  runs  over  both 
TCP  and  UDP  port  53.  Identifying  traffic  on  UDP  port  53  will  be  critical  in  detecting 
DNS  exhltration  attempts. 

The  primary  problem  with  port  matching  is  that  some  applications  are  not 
anchored  to  a  port  or  port  range.  For  example,  the  Bit  Torrent  protocol  is  not  anchored 


15 


to  a  single  port.  Bit  Torrent  users  have  the  option  to  manually  assign  a  port  number 
to  use  or  allow  the  client  program  to  randomly  assign  one.  Malicious  insiders  could 
potentially  run  Bit  Torrent  through  port  80,  a  port  open  on  most  enterprise  networks 
for  web  traffic  [GonOS].  Only  a  detailed  packet  inspection  would  reveal  the  true 
nature  of  the  traffic.  Research  shows  up  to  70%  of  Internet  traffic  is  unidentihable 
strictly  based  on  port,  underlining  the  futility  in  identifying  traffic  solely  based  on 
port  matching  [MW06]. 

2.2.2  Payload  Analysis.  The  next  step  in  classifying  network  traffic  can 
be  done  by  analyzing  the  payload.  The  payload  of  packets  contains  certain  byte 
strings  signifying  the  use  of  a  certain  application  or  protocol.  Sen  et  al.  developed  an 
approach  to  identify  peer-to-peer  protocols  based  on  application-level  signatures.  The 
protocols  researched  were  Gnutella,  eDonkey,  Direct  Gonnect,  Kazaa,  and  Bit  Torrent. 
With  the  Bit  Torrent  protocol,  there  is  no  signaling  traffic  between  the  client  server 
and  tracker  server.  Sen,  et  al.  identihed  Bit  Torrent  traffic  by  the  distinct  Bit  Torrent 
handshake  message  [SSW04].  The  Bit  Torrent  handshake  message  has  the  following 
format: 

<0xl3><BitTorrent  Protocol> 

The  Bit  Torrent  20-byte  signature  is  at  a  hxed  location  in  the  payload  making  its 
identihcation  accurate  [SSW04].  This  makes  payload  analysis  an  attractive  method 
for  detecting  Bit  Torrent  traffic  because  of  the  unique  signature.  Additionally,  Sen, 
et  al.  found  a  virtual  0%  false  positive  and  10%  false  negative  detection  rate  for 
identifying  the  peer-to-peer  traffic  [SSW04]. 

Payload  analysis  is  effective  in  identifying  Bit  Torrent  payloads  that  have  not 
been  obfuscated.  The  simple  technique  of  byte  padding  can  render  these  payload- 
based  analyzers  useless,  unless  they  are  modihed  to  search  through  the  entire  payload 
for  the  specihc  string.  Network  traffic  and  payload  obfuscation  methods  are  discussed 
in  Section  2.3. 
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2.2.3  Behavioral  Analysis.  The  last  method  of  classifying  network  traffic 
is  to  examine  it  at  the  transport  layer.  Karagiannis,  et  ah  developed  a  systematic 
method  of  identifying  peer-to-peer  traffic  flows  at  the  transport  layer  while  relegating 
the  accuracy  of  the  previously  discussed  port  matching  and  payload  analysis  meth¬ 
ods  [KBFC04].  Their  methodology  focuses  on  two  metrics  when  analyzing  packet 
headers  to  detect  peer-to-peer  traffic  flows.  The  first  metric  is  to  observe  source- 
destination  IP  pairs  that  are  using  both  TCP  and  UDP  transfers,  a  common  mark  of 
peer-to-peer  protocols.  However,  other  applications  also  use  TCP/UDP  pairs,  such  as 
DNS,  Network  Basic  Input/Output  System  (NetBIOS),  Internet  Relay  Chat  (IRC), 
and  gaming  applications,  so  those  application  layer  protocols  are  ignored  [KBFC04]. 

The  second  metric  is  observing  connection  characteristics  of  {IP,  port}  pairs. 
When  a  host  joins  a  peer-to-peer  network,  it  consults  its  starting  host  cache  for  the 
IP  address  of  other  peers  or  servers.  After  a  connection  is  established  between  the 
host  and  another  peer,  the  host  advertises  its  IP  address  and  port  number  to  receive 
connections.  It  is  essentially  the  host’s  identihcation  in  the  peer-to-peer  network. 
When  twenty  different  peers  decide  to  connect  to  the  host,  the  traffic  will  reveal 
twenty  distinct  IP  addresses  with  twenty  distinct  source  ports  all  connected  to  the 
host.  The  equality  of  distinct  IP  addresses  and  ports  (e.g.,  20  distinct  IP  addresses 
with  20  unique  ports)  signifies  a  probable  peer-to-peer  connection  [KBFC04]. 

Behavioral  Analysis  is  effective  in  quickly  identifying  traffic  based  on  the  5- 
tuple  (source  IP,  source  port,  destination  IP,  destination  port,  transport  layer  pro¬ 
tocol}  across  a  network  backbone.  It  can  also  be  used  to  identify  new  peer-to-peer 
applications  or  protocols  that  have  been  modihed.  There  are  several  drawbacks  with 
this  heuristic  for  detecting  peer-to-peer  traffic.  First,  the  method  cannot  detect  the 
specihc  peer-to-peer  protocol  or  the  payload  being  transferred.  Furthermore,  the  Bit- 
Torrent  protocol  is  not  one  of  the  six  peer-to-peer  protocols  analyzed  that  relies  on 
TCP/UDP  pairs.  Secondly,  the  95%  peer-to-peer  flow  detection  rate,  coupled  with 
the  8%  to  12%  false  positive  rate,  makes  it  an  effective,  but  not  guaranteed,  method 
of  detecting  peer-to-peer  traffic  [KBFC04] . 
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2.3  Network  Traffic  and  Data  Obfuscation  Methods 

In  certain  cases  it  is  important  to  encrypt  data  and  traffic  for  security  reasons, 
such  as  online  credit  card  transactions  or  when  sending  conhdential  emails.  It  is 
also  important  in  some  cases  for  journalists,  whistleblowers,  and  citizens  of  repressed 
regimes  to  retain  anonymity.  However,  the  same  methods  of  encrypting,  obfuscating, 
and  anonymizing  data  can  be  used  for  illicit  purposes.  These  methods  include  byte 
padding,  Ron’s  Code  4  (RC4)  encryption.  Virtual  Private  Network  (VPN)  tunnels, 
and  Secure  Shell  (SSH)  tunnels,  darknets,  and  the  Tor  network. 

2.3.1  Byte  Padding.  Byte  padding  is  the  most  primitive  obfuscation  method 
used  to  hide  payloads  in  network  traffic.  When  byte  padding  is  used,  a  series  of 
random  characters  is  prepended  to  the  payload  to  trick  elementary  packet  analyzers 
(see  Section  2.2.2).  The  packet  analyzer  will  identify  the  payload  as  encrypted  or 
unknown  since  it  does  not  match  any  known  payload  signatures. 

Although  byte  padding  is  a  cheap  and  easy  method  of  obfuscating  data,  it  suffers 
two  major  weaknesses.  The  hrst  is  that  the  payload  is  still  readable  within  the  packet, 
it  is  simply  in  a  different  location.  Smart  analyzers  can  sequentially  search  for  the 
byte  string  in  the  payload,  but  this  takes  more  time.  The  second  problem  is  that 
only  the  payload  is  obfuscated  and  not  the  entire  conversation.  This  allows  network 
flow-based  algorithms  to  identify  the  network  protocol  being  used. 

2.3.2  Ron’s  Code  4-  The  Ron’s  Code  4  (RC4)  algorithm  was  invented  by 
Ronald  Rivest  from  RS A  Security  in  1987  [Riv09]  [Sta06] .  RC4  is  a  variable  key-size 
stream  cipher  that  relies  on  single  byte  operations  [RSA09].  The  cipher  performs 
quickly  in  software  and  has  been  implemented  in  Secure  Socket  Layer  protocol  com¬ 
munication,  Lotus  Notes,  Oracle  Secure  SQL,  and  in  the  Wired  Equivalent  Privacy 
security  for  IEEE  802.11  [Tec09].  Another  use  of  the  RC4  cipher  is  in  payload  ob¬ 
fuscation  of  Bit  Torrent  packets.  The  cipher  can  perform  faster  than  other  symmetric 
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stream  ciphers  as  seen  in  Table  2.1.  The  table  categorizes  different  ciphers,  the  key 
length,  and  the  speed  of  the  encryption  cipher  in  Mbps. 


Table  2.1:  Speed  Comparisons  of  Symmetric  Ciphers  on  a  Pentium  II  [Sta06]. 


Cipher 

Key  Length 

Speed  (Mbps) 

DES 

56 

9 

3DES 

168 

3 

RC2 

variable 

0.9 

RC4 

variable 

45 

2.3.3  Virtual  Private  Network  and  Secure  Shell  Tunnels.  One  method  of 
obfuscating  network  data  and  the  traffic  is  to  use  a  tunnel.  Tunnels  allow  one  protocol 
to  be  transferred  over  another  protocol.  Common  tunneling  applications  include  VPN 
and  SSH.  Gebski  et  al.  assert  the  difficulty  in  identifying  the  underlying  protocols 
because  the  entire  packet  is  scrambled  and  encrypted,  as  are  any  useful  fields  in  the 
TCP/IP  header  [GPW06]. 

In  the  VPN  and  SSH  obfuscation  methods,  an  encrypted  tunnel  is  established 
between  the  downloader  and  uploader.  Network  data  and  traffic  are  transmitted  only 
after  the  tunnel  has  been  established.  The  network  data  and  traffic  are  encapsulated 
with  an  SSH  or  VPN  header,  thus  encrypting  the  entire  network  conversation  instead 
of  just  the  payload.  Analyzers  of  the  network  traffic  will  only  be  able  to  identify  the 
source  and  destination  IP  addresses,  approximate  packet  size,  and  timing  of  the  traf¬ 
fic  [GPW06].  Despite  the  limited  information  leaked  by  VPN  and  SSH  connections, 
Gebski  et  al.  correctly  identified  encapsulated  BitTorrent  traffic  90.5%  of  the  time 
using  bipartite  graphs  of  outgoing-incoming  node  pairs  [GPW06].  This  discovery  was 
supported  when  Wright  et  al.  were  able  to  accurately  track  the  flows  of  encrypted 
tunnels  carrying  a  single  application  protocol  [WMM06] .  It  should  be  noted  that  both 
of  these  methods  of  inferring  the  underlying  traffic  are  still  unable  to  conclude  what 
the  packets  contain. 
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2.3.4  Darknets.  An  even  more  clandestine  form  of  file  sharing  and  commu¬ 
nication  is  rising  in  the  form  of  Darknets.  Biddle  et  ah  of  Microsoft  hrst  addressed  the 
rise  of  content  distribution  and  peer-to-peer  networks  in  their  2002  paper  entitled  “The 
Darknet  and  the  Future  of  Content  Distribution.”  They  concluded  that  Darknet- 
based  peer-to-peer  hie  sharing  technologies  were  growing  in  convenience,  bandwidth, 
and  efficiency  and  would  not  likely  encounter  technical  impediments  [BEPW02]. 

The  dehnition  of  a  Darknet  has  evolved  from  any  public  peer-to-peer  network, 
such  as  Bit  Torrent,  Usenet,  and  Gnutella,  to  any  network  that  is  friend-to-friend  ori¬ 
ented.  These  Darknets,  as  opposed  to  the  public  Lightnets,  are  based  on  a  “members 
only”  camaraderie  and  trust  between  members.  Darknets  are,  in  the  truest  sense, 
nearly  impossible  to  hnd.  However,  there  is  software  available  to  the  public  to  es¬ 
tablish  Darknets  [Fil07].  Two  of  the  most  popular  Darknet  software  applications  are 
Freenet  and  WASTE.  The  availability  of  public  software  to  join  and  establish  private 
Darknets  makes  it  difficult  to  detect  illicit  hie  transfers  and  possible  private  VoIP 
connections. 

2.3.4. 1  Freenet.  Freenet  is  a  software  application  allowing  users  to 
publish  and  retrieve  information  without  the  fear  of  being  censored  [Fre09] .  Freenet 
can  be  described  as  an  “Internet  within  an  Internet”  that  relies  on  encrypted  commu¬ 
nication  between  other  nodes.  Users  contribute  to  the  Freenet  project  by  providing 
bandwidth  for  routing  and  a  piece  of  their  hard  drive,  called  the  data  store,  to  hold 
encrypted  data.  The  user  is  oblivious  to  the  content  being  stored  in  the  data  store, 
thus  making  it  difficult  for  prosecution  of  possession  of  illegal  or  copyrighted  mate¬ 
rial.  The  data  is  automatically  added  and  deleted  based  on  the  popularity  of  certain 
content  and  the  needs  of  Freenet  [Fre09] . 

2. 3.4. 2  WASTE.  WASTE  is  a  software  application  and  protocol  that 
caters  to  smaller  groups  of  10-50  nodes.  It  provides  an  anonymous,  secure,  and 
encrypted  collaboration  tool  to  share  ideas  and  data  [WAS09].  WASTE  implements 
a  decentralized  distributed  architecture  for  nodes  to  create  a  partial  mesh  network. 
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Security  features  include  link-level  encryption  using  Blowfisli  and  RSA  public  keys  for 
authentication.  This  application  allows  trusted  users  to  securely  trade  possibly  illicit 
or  illegal  hies  with  each  other  [WAS09]. 

2.3.5  The  Onion  Router  Network.  The  last  method  of  obfuscating  and 
hiding  network  traffic  data  is  The  Onion  Router  (Tor)  network.  Tor  is  the  most 
popular  and  “good  intentioned”  anonymizer  allowing  users  to  maintain  privacy  and 
security  on  the  public  Internet  through  numerous  layers.  The  benehts  of  Tor  include 
security  and  privacy  by  using  a  distributed  network  of  relays  to  bounce  traffic.  It  is 
supposed  to  prevent  monitoring  and  the  revealing  of  your  physical  location  [Tor09a] . 
These  indirect  and  random  data  pathways  make  it  difficult  for  sophisticated  traffic 
analysis  to  take  place. 

Tor  could  technically  be  considered  a  Darknet,  but  the  intentions  and  goals 
of  the  project  seem  to  separate  it  from  the  negative  connotations  associated  with 
Darknets.  Some  government  entities  use  Tor  as  well.  The  United  States  Navy  uses  Tor 
for  open  source  intelligence  gathering  and  law  enforcement  uses  Tor  to  anonymously 
survey  web  sites  [Tor09b].  The  technical  aspects  of  Tor  are  similar  to  Freenet  and 
WASTE,  in  which  users  can  voluntarily  route  traffic  throughout  the  network. 

Tor  differs  from  VPNs  and  other  encrypted  tunnels  in  that  it  is  not  susceptible 
to  timing  and  communication  analysis.  Despite  the  best  intentions  of  the  Tor  network, 
illicit  hie  sharers  can  still  use  it  to  transfer  illegal  material. 

2.4  Current  Methods  for  Detecting  Illicit  Traffic 

There  are  many  methods  currently  available  to  detect  illicit  traffic.  This  sections 
covers  the  simpler,  software-based  solutions  such  as  using  Snort  rules  and  progresses 
towards  the  more  intelligent  solutions  that  utilize  artihcial  intelligence. 

2.4.1  Wireshark.  Wireshark  is  one  of  the  most  popular  network  protocol 
analyzers.  It  is  the  standard  for  analyzing  traffic  and  simple  network  troubleshooting. 
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It  runs  as  a  software  application  on  a  system  and  requires  a  network  card  that  can 
be  set  to  promiscuous  mode.  Wireshark  will  display  all  of  the  incoming  and  outgoing 
packets  on  an  interface,  but  allows  the  user  to  hlter  the  results  by  protocol,  IP  address, 
or  port  number,  to  name  a  few.  The  advantages  of  Wireshark  are  that  it  is  free, 
reliable,  and  easy  to  use  on  a  small  scale.  The  disadvantages  of  Wireshark  include 
operating  at  the  application  layer  and  the  inability  to  perform  complex  traffic  analysis 
[Wir09]. 

2.4-2  Snort.  Snort  is  an  open  source  intrusion  detection  and  prevention 
system  designed  to  be  implemented  in  software.  It  is  a  rule-based  application  that 
can  perform  real-time  traffic  analysis  and  packet  logging  on  IP  networks.  Snort  is 
capable  of  protocol  analysis,  content  searching  and  matching,  and  attack  detection 
by  relying  on  a  flexible  rule  set  used  to  describe  the  handling  of  certain  traffic.  Snort 
has  three  modes  of  operation:  packet  sniffer,  packet  logger,  or  a  complete  Intrusion 
Prevention  System  [SnolO].  Snort  is  a  powerful  and  highly-regarded  Intrusion  Pre¬ 
vention  System  for  providing  network  security.  However,  Snort  has  two  shortfalls. 
First,  Snort  must  be  installed  and  run  on  a  dedicated  and  powerful  computer  because 
of  the  processor-intensive  rules.  Large  rule  sets  can  deteriorate  the  performance  of 
Snort  if  it  is  processing  all  inbound  and  outbound  traffic.  This  scenario  could  lead  to 
possible  missed  critical  Bit  Torrent,  SIP,  or  DNS  packets.  Secondly,  since  Snort  and 
the  Snort  rules  are  open  source,  the  code  can  be  analyzed  to  determine  how  to  avoid 
detection  [SnolO]. 

2.4.3  Hi- Performance  Protocol  Identification  Engine.  The  Hi-Performance 
Protocol  Identification  Engine  (HiPPIE)  is  another  software-based  protocol  analyzer. 
It  differs  from  Wireshark  in  that  it  attempts  to  analyze  traffic  and  protocols  heuris- 
tically.  Some  of  the  more  impressive  features  include  Session  Prediction  Support  and 
Tunneled  Protocol  Tracking.  The  Session  Prediction  Support  has  the  ability  to  pre¬ 
dict  upcoming  protocol  sessions.  The  Tunneled  Protocol  Tracking  feature  identifies 
the  internal  protocol  being  used  with  a  tunneling  protocol  [HiP09b]. 
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The  HiPPIE  advertises  three  main  functionalities  [HiP09a].  The  main  function¬ 
alities  include: 

1.  Passive  traffic  analyzer:  HiPPIE  must  be  installed  in  the  kernel  of  a  Linux 
system  and  configured  to  push  traffic  to  a  single-sourced  bridge  interface. 

2.  Inline  Protocol/Packet  Filter:  This  method  entails  establishing  a  Linux  system 
with  HiPPIE  as  either  an  in-line  bridge  or  routing  device  that  forces  traffic 
through  using  integrated  Nethlter  or  IPTables  to  hlter  traffic.  It  also  allows 
network  administrators  to  tag  or  limit  certain  types  of  traffic  based  on  HiPPIE’s 
recognition  capabilities. 

3.  Plug-in  to  a  third  party  system:  This  option,  although  not  completed,  allows 
administrators  to  pass  traffic  from  a  traffic  sniffing  application,  such  as  tcpdump, 
to  be  analyzed  by  HiPPIE. 

The  downside  of  the  HiPPIE  system  is  that  it  does  not  perform  payload  inspec¬ 
tion,  only  protocol  analysis  [HiP09b].  Payload  inspection  consists  of  examining  the 
contents  of  a  packet.  Protocol  Analysis  only  inspects  the  headers  to  determine  what 
protocol  is  being  transmitted. 

2.4-4  BitTorrent  Monitoring  System.  Another  method  of  detecting  and 
tracking  illicit  hies  is  the  BitTorrent  Monitoring  (BTM)  system,  created  by  Chow, 
et  ah  The  BTM  is  an  automatic,  rule-based  software  application  to  monitor,  record, 
and  analyze  BitTorrent  traffic  [CCM+07].  Figure  2.4  illustrates  how  the  BTM  system 
works.  The  BTM  is  divided  into  two  different  modules,  the  Torrent  Searcher  and 
Torrent  Analyzer. 
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Figure  2.4:  The  Bit  Torrent  Monitoring  System  Process  [CCM+07]. 


The  Torrent  Searcher  is  a  passive  reconnaissance  function  to  collect  torrents  of 
interest.  The  BTM  commences  by  searching  public  forums  and  web  sites  for  torrent 
hies  and  exploring  the  various  hyperlinks.  This  depth-hrst  search  continues  until  a 
predehned  level  has  been  reached.  Each  torrent  hie  and  webpage  containing  prede- 
hned  keywords  of  interest  are  downloaded  and  archived  to  the  local  investigator’s 
computer  [CCM+07]. 

The  Torrent  Analyzer  is  the  interactive  portion  of  the  BTM  since  it  commu¬ 
nicates  with  trackers  to  retrieve  the  list  of  peers  sharing  the  hie.  Responses  from 
the  trackers  and  peers  are  recorded  by  the  BTM  for  future  analysis.  The  BTM 
has  a  real-time  attributed-based  rule  engine  to  hag  specihc  tracker  or  peer  informa¬ 
tion  [CCM+07]. 

The  fundamentals  of  the  BTM  system  are  sound,  but  there  are  several  con¬ 
cerns  to  consider.  First,  the  scope  of  the  system  is  limited  due  to  the  immense  vol¬ 
ume  of  torrent  hies  on  the  Internet.  Two  of  the  larger  tracker  sites,  piratebay.org 
and  isohunt .  com,  contain  approximately  1.8  million  and  1.7  million  torrents,  respec¬ 
tively  [Bay09]  [ISO09].  Secondly,  the  huctuating  list  of  peers  associated  with  a  torrent 
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changes  by  the  minute,  making  the  BTM  system  less  than  ideal  for  associating  specific 
IPs  with  a  hie  [CCM+07]. 

2.4-5  Entropy-Based  Malicious  DNS  detection.  As  mentioned  earlier,  the 
DNS  protocol  can  be  abused  to  exhltrate  data  or  be  used  as  a  command  and  con¬ 
trol  channel  for  botnets.  Typically,  DNS  traffic  is  minimal  between  clients  (DNS 
resolvers)  and  servers  (DNS  servers).  Romana  et  al.  performed  an  entropy  study  of 
external  DNS  query  traffic  to  the  university  network’s  top  domain  server.  Any  peak 
in  the  entropy  was  assumed  to  be  associated  with  spam  botnet  activity  [RKSM08]. 
Figure  2.5  illustrates  the  entropy  changes  in  source  IP  addresses  and  the  DNS  query 
contents-based  parameters. 


Time  (day) 

Figure  2.5:  Entropy  Changes  In  the  Domain  Name  System  External  Query  Traf- 
£c  [RKSM08]. 


The  drastic  changes  in  entropy,  denoted  as  the  spikes,  were  hypothesized  to 
be  botnets  used  to  communicate,  exhltrate  data,  or  perform  other  malicious  mis- 
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sions.  Botnet  infection  was  verified  on  the  computers  after  performing  forensic  anal¬ 
ysis  [RKSM08]. 

2.4-6  Cross  Entropy-Based  Malicious  DNS  detection.  Karasaridis  et  al.  de¬ 
veloped  a  DNS  Tunneling  Attack  Detector  (TUNAD)  to  detect  suspicious  DNS  packet 
size  anomalies  in  real-time  [KMHH06].  Outlying  packet  sizes  are  usually  indicative 
of  malicious  tunneling  over  DNS.  Their  approach  is  as  follows: 

1.  Separate  DNS  packets  into  three  types  and  calculate  the  frequency 
of  non-conforming  UDP  DNS  packet  sizes: 

•  Requests:  source  port,  sport>1023  and  destination  port,  dport=53. 
The  size  cannot  exceed  300  bytes. 

•  Response:  source  port,  sport=53  and  destination  port,  dport>1023. 
These  are  normally  less  than  512  bytes. 

•  Unknown:  Response  or  request  certainty  is  unknown,  with  sport=53 
and  dport=53.  These  are  normally  less  than  512  bytes. 

2.  Measure  the  exact  packet  size  using  single  packet  flow  records. 

3.  Calculate  hourly  packet  size  histograms  for  each  circuit  and  packet 
type. 

4.  Use  a  Cross  Entropy-based  anomaly  detector  on  the  packet  size  his¬ 
tograms. 

The  algorithm  then  computes  the  Cross  Entropy,  Self  Entropy,  and  Relative 
Entropy  to  detect  anomalies.  The  algorithm  was  successful  in  detecting  a  change  in 
Relative  Entropy  of  packet  sizes  on  September  30,  2003  before  reports  surfaced  about 
the  Sinit  Trojan  that  used  port  53.  This  method  of  calculating  changes  from  a  relative 
baseline  is  important  in  detecting  suspicious  DNS  traffic  [KMHH06]. 


2.4.7  Detecting  DNS  Tunnels  Using  Artificial  Neural  Networks.  In  2009, 
jhind  presented  research  on  detecting  DNS  tunnels  using  artificial  intelligence  called 
dnsTTrap  [jhilO].  The  algorithm  relies  on  Artificial  Neural  Networks.  The  algorithm, 
also  called  supervised  learning,  works  as  follows: 

1.  Receive  inputs  (number  of  packets  to  domain,  average  length  of  packets  to 
domain,  average  number  of  distinct  characters  in  the  lowest  level  domain) 


26 


2.  Give  them  values  (assign  weights) 

3.  Adapt  decisions  until  inputs  match  training  data  (set  thresholds) 

The  goal  was  to  examine  the  entropy  of  the  data  contained  in  the  lowest  level 
domain.  The  reasoning  is  that  if  data  is  being  exhitrated  by  the  lowest  level  domain, 
the  content  of  each  lowest  level  domain  will  be  entropic.  Each  lowest  level  domain 
is  assigned  a  numerical  value,  allowing  comparison  between  other  lowest  level  do¬ 
mains.  For  example,  the  domains  mail.example.com  and  mail2.example.com  will 
have  minimal  entropy  between  them.  However,  the  domains,  4ryf76df.hacker.com 
and  73bfdd7r.hacker.com  will  have  greater  entropy  and  can  be  classihed  as  a  possi¬ 
ble  DNS  tunnel.  The  last  step  is  to  train  the  neural  net  using  data  controlled  by  the 
user.  False  negatives  are  added  to  the  training  list  and  the  system  is  retrained  [jhilO]. 

The  system  managed  to  detect  DNS  tunnels  created  by  the  DNS  tunneling  ap¬ 
plications  Iodine,  OzymanDNS,  and  tcp2dns.  However,  the  system  lacks  real-time 
detection  since  it  only  works  against  previously  captured  tcpdump  hies.  In  addition, 
the  system  only  analyzes  the  lowest  level  domain,  instead  of  the  entire  domain.  DNS 
tunneling  applications  can  be  modihed  to  transfer  data  at  diherent  levels  of  the  do¬ 
main,  such  as  exfiltrated_data.mail.example.com 
to  mail.exfiltrated_data.example.com  [jhilO]. 

2.5  The  Substitute  Database  Manager  Hashing  Function 

A  new  feature  of  the  TRAPP-2  system  is  the  implementation  of  a  hashing  func¬ 
tion  used  in  the  Substitute  Database  Manager  (sdbm)  library.  The  hashing  function 
converts  arbitrary-length  strings  into  eight-byte  hashes.  The  arbitrary-length  strings 
in  this  case  are  SIP  URIs  and  DNS  domains.  The  sdbm  hashing  function  is  selected 
over  more  proven  hashing  functions  such  as  SHA-1  and  MD5  because  it  is  quick  and 
easy  to  implement.  Further  justification  of  the  feature  can  be  found  in  Section  3.2.2. 

In  December  1990,  Ozan  Yigit  released  the  sdbm  library  into  the  public  do¬ 
main  as  an  alternative  to  the  original  Database  Manager  (dbm)  database  engine,  and 
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subsequent  New  Database  Manager  (ndbm)  database  engine,  developed  by  AT&T  in 
1979  [YiglOb]  [SY91].  The  sdbm  library  is  a  clone  of  the  ndbm  library  and  parallels 
the  functionality.  However,  the  sdbm  library  relies  on  the  simple  hashing  algorithm 
found  below,  implemented  in  the  C  programming  language  [YiglOa]. 

static  unsigned  long  sdbm (unsigned  char  *str){ 
unsigned  long  hash  =  0; 
int  c; 

while  (c  =  *str++) 

hash  =  c  +  (hash  «  6)  +  (hash  «  16)  -  hash; 
return  hash; 

> 

According  to  the  creator,  Ozan  Yigit,  sdbm  “was  found  to  do  well  in  scrambling 
bits,  causing  better  distribution  of  the  keys  and  fewer  splits.  It  also  happens  to  be  a 
good  general  hashing  function  with  good  distribution”  [YiglOa].  The  hashing  func¬ 
tion’s  speed  (See  Appendix  B),  eight-byte  hashes,  and  easy  software  implementation 
made  it  an  ideal  hashing  function  for  the  TRAPP-2  system.  While  using  the  hashing 
function,  one  drawback  occasionally  noted  is  the  minimal  avalanche  effect  in  which 
changing  a  DNS  domain  by  one  bit  (e.g.,  from  123 .  com  to  124 .  com)  changes  the  hash 
by  one  bit.  Another  possible  drawback  is  the  number  of  collisions  between  hashes. 
This,  however,  is  not  investigated  since  the  assumption  is  that  an  administrator  will 
review  the  packets  and  their  hashed  domains. 

2.6  The  Tracking  and  Analysis  for  Peer-to-Peer  System 

A  FPGA-based  packet  analyzer  was  developed  in  2008  to  detect  peer-to-peer 
protocols  traversing  a  network.  The  TRAPP  system  was  built  specifically  to  detect 
BitTorrent  and  VoIP  traffic.  The  TRAPP  system  was  created  as  an  alternative  to 
current  illegal  hie  detection  techniques  such  as  software  packet  sniffers  and  the  Bit- 
Torrent  Monitoring  System.  A  discussion  of  these  various  techniques  can  be  found 
in  Section  2.4.  The  current  TRAPP  system  is  built  on  a  Xilinx  Virtex-II  Pro  FPGA 
board.  The  TRAPP  system,  capabilities,  and  limitations  are  expanded  to  better 
understand  the  state  of  the  system  [Sch09]. 


2.6.1  Capabilities.  The  TRAPP  system  is  designed  to  operate  at  the  gate¬ 
way  between  the  Internet  and  a  government  local  area  network  (LAN).  It  is  not  placed 
in-line  with  traffic  entering  or  exiting  the  local  network,  so  if  the  TRAPP  system  fails, 
the  network  will  still  remain  viable.  Instead,  it  is  placed  on  the  Switched  Port  Ana¬ 
lyzer  (SPAN)  port  of  a  switch.  The  switch  is  conhgured  to  send  packets  to  the  correct 
destination  in  addition  to  the  SPAN  port.  This  makes  the  TRAPP  system  virtually 
invisible  and  undetectable  to  both  normal  and  malicious  users.  The  TRAPP  system 
extracts  the  Bit  Torrent  hie  hash  or  SIP  URI  and  compares  it  against  a  list  of  known 
contraband  hie  hashes  or  SIP  identihers.  The  detection  of  the  contraband  hies  and 
SIP  identihers  is  done  in  real-time.  Figure  2.6  is  a  howchart  overview  of  how  the  sys¬ 
tem  works  [Sch09].  The  TRAPP  system  analyzes  every  packet  howing  through  the 
network  switch,  looking  for  a  Bit  Torrent  or  SIP  signature.  If  the  packet  has  a  Bit- 
Torrent  or  SIP  signature,  the  hash  or  SIP  URI  are  extracted,  respectively.  A  binary 
search  is  performed  on  the  extracted  hash  against  a  blacklist  of  Bit  Torrent  hashes  or 
SIP  URIs.  If  a  match  is  found,  the  packet  is  logged,  else  it  is  dropped  [Sch09]. 

2.6.2  Limitations.  There  are  several  limitations  with  the  TRAPP  system. 
These  limitations  include  the  hardware,  contraband  hie  list  size,  SIP  URI  extraction, 
and  lack  of  malicious  DNS  traffic  detection  [Sch09]. 

The  hrst  limitation  of  the  TRAPP  system  is  the  hardware.  The  hardware  com¬ 
ponents  of  interest  on  the  Xilinx  Virtex-II  Pro  FPGA  board  are  the  100  megabit 
Ethernet  card  and  300  MHz  processor  [XilOS],  which  are  suitable  for  smaller  LANs 
with  less  traffic  to  compare  against  the  contraband  list.  In  reality,  the  size  of  govern¬ 
ment  networks,  traffic,  and  bandwidth  requirements  justify  faster  hardware. 

Another  drawback  of  the  TRAPP  system  is  the  size  of  the  contraband  list.  The 
TRAPP  system  relies  on  64  KB  of  memory  to  store  the  blacklist  of  Bit  Torrent  hie 
hashes  and  SIP  identihers.  The  size  of  the  list  is  limited  to  1000  entries  [Sch09].  This 
size  is  appropriate  for  a  hrst  iteration  proof-of-concept  system,  but  in  reality,  the  list 
size  needs  to  be  much  larger. 
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Figure  2.6:  TRacking  and  Analysis  for  Peer-to-Peer  System  Flowchart  [Sch09]. 


The  third  limitation  is  how  TRAPP  deals  with  processing  SIP  packets.  The 
TRAPP  system  only  extracts  the  hrst  12  bytes  of  a  SIP  URL  For  example,  if  the  SIP 
URI  is  2001010 .1.1. 50,  the  TRAPP  system  extracts  2001010 .1.1.  and  compares  it 
against  the  list  of  interest  [Sch09].  Although  feasible,  this  logic  is  not  realistic.  This 
limitation  is  elaborated  on  in  Section  3.2.2. 
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Lastly,  the  TRAPP  system  is  unable  to  detect  illicit  DNS  traffic.  Hackers  and 
malicious  users  abuse  the  DNS  protocol  to  transfer  data  and  information,  in  addition 
to  communicating  with  botnets  [Sch09] . 

2. 7  Summary 

This  chapter  discusses  the  illicit  traffic  and  protocols  of  interest  for  this  research, 
specihcally  Bit  Torrent,  VoIP,  and  DNS.  The  traditional  methods  of  classifying  net¬ 
work  traffic  such  as  port  matching  are  examined.  This  is  followed  by  exploring  the 
current  methods  of  obfuscating  and  encrypting  network  data  and  traffic.  The  current 
methods  of  identifying  and  detecting  these  types  of  traffic,  both  clear  and  encrypted, 
are  also  summarized.  The  details  of  the  sdbm  hashing  function  are  also  expanded. 
Finally,  a  review  of  the  TRAPP  system’s  capabilities  and  limitations  are  detailed. 
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III.  Methodology 


This  chapter  explains  the  methods  used  to  evaluate  the  performance  of  the 
TRAPP-2  system.  The  two  metrics  measured  are  packet  processing  time  and 
the  probability  of  packet  intercept.  The  first  section  details  the  Goals  and  Hypotheses. 
Section  3.2  outlines  the  Approach,  and  Section  3.3  outlines  the  System  Boundaries. 
The  System  Workloads  are  defined  in  Section  3.5,  followed  by  Performance  Metrics 
in  Section  3.6,  System  Parameters  in  Section  3.7,  and  Factors  in  Section  3.8.  The 
last  three  sections  include  the  Evaluation  Technique  in  Section  3.9,  the  Experimental 
Design  in  Section  3.10,  and  the  Summary  in  Section  3.11. 

3.1  Goals  and  Hypotheses 

The  objective  of  this  research  is  to  test  and  evaluate  the  performance  of  the 
TRAPP-2  system  that  detects  packets  of  interest  traversing  a  gigabit  Ethernet  net¬ 
work.  The  packets  of  interest  include  Bit  Torrent  handshake  packets  with  file  hashes 
of  interest,  SIP  Uniform  Resource  Identifiers  (URI)  of  interest,  and  suspicious  DNS 
traffic.  The  TRAPP-2  system  detects  these  transmissions,  classifies  the  traffic,  ex¬ 
tracts  the  payload  (and  sdbm  hashes  it  for  SIP/DNS  domains),  compares  the  hash 
against  a  list,  and  records  the  transmission  information. 

The  goals  of  this  research  are  to: 

1.  Determine  the  packet  processing  times  for  packets  of  interest. 

2.  Determine  the  probability  of  packet  intercept  under  a  flood  of  packets  of  interest. 

3.  Determine  the  probability  of  packet  intercept  under  various  network  utilizations. 

4.  Determine  how  increasing  the  hash  list  size  affects  the  packet  processing  time. 
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The  hypotheses  of  this  research  are: 


1.  The  TRAPP-2  system  can  process  every  type  of  packet  under  35,000  CPU 
cycles. 

2.  The  TRAPP-2  system  can  detect  over  50%  of  packets  of  interest  flooded  into 
the  system. 

3.  The  TRAPP-2  system  can  detect  and  process  Bit  Torrent  and  DNS  packets  with 
at  least  a  90%  probability  of  packet  intercept  under  a  90%  network  utilization. 
Furthermore,  it  is  hypothesized  that  the  TRAPP-2  system  can  detect  and  pro¬ 
cess  SIP  INVITE  and  SIP  BYE  packets  with  at  least  a  19%  probability  of  packet 
intercept  under  a  90%  network  utilization. 

4.  The  TRAPP-2  system’s  mean  packet  processing  time  will  increase  by  no  more 
than  50  CPU  cycles  each  time  the  hash  list  size  is  doubled. 

Four  experiments  are  conducted  to  determine  if  the  TRAPP-2  system  meets 
the  goals  and  hypotheses.  Figure  3.1  summarizes  the  experiments,  metrics,  and  goals 
used  to  evaluate  the  performance  of  the  TRAPP-2  system. 


Experiment 

Metric 

Goai 

1 

Packet  Processing  Time 

Determine  the  packet  processing  times 
for  packets  of  interest 

2 

Probability  of  Packet  Intercept 

Determine  the  probability  of  packet 
intercept  under  a  flood  of  packets  of 
Interest 

3 

Probability  of  Packet  Intercept 

Determine  the  probability  of  packet 
intercept  under  various  network 
utilizations 

4 

Packet  Processing  Time 

Determine  how  increasing  the  hash  list 
size  affects  the  packet  processing  time 

Figure  3.1:  Summary  of  Experiments  for  the  TRacking  and  Analysis  for  Peer-to- 

Peer  2  System. 
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3. 2  Approach 

The  TRAPP-2  system  is  developed  on  the  Xilinx  ML510  FPGA.  The  reason  for 
developing  the  TRAPP-2  system  on  an  FPGA  board  is  similar  to  the  original  TRAPP 
system,  henceforth  referred  to  as  “TRAPP-1”  in  this  research.  The  system’s  simplicity 
and  speed  is  maximized  by  allowing  the  software  application  to  directly  access  the 
Ethernet  controller  buffers  [Sch09].  In  addition,  hardware  components  can  easily  be 
added  with  minimum  overhead.  Some  elements  and  functions  from  the  TRAPP- 1 
system  are  used  for  the  TRAPP-2  system,  but  a  majority  of  the  code  is  rewritten 
to  function  with  the  updated  FPGA  hardware  and  research  goals.  Although  both 
systems  work  similarly,  major  hardware  and  software  changes  are  required  to  achieve 
proper  functionality  in  the  TRAPP-2  system.  A  review  of  the  TRAPP- 1  system  can 
be  found  in  Section  2.6. 

3.2.1  Hardware  Modifications.  The  major  hardware  modihcation  between 
the  TRAPP-1  and  TRAPP-2  systems  is  the  Ethernet  controller.  The  TRAPP-1 
system  relies  on  the  EthernetLite  core  peripheral,  which  has  an  upper  limit  of  100 
Mbps.  For  the  TRAPP-2  system,  a  Trimode  Ethernet  Media  Access  Gontroller  is 
used  to  receive  Ethernet  frames  at  1000  Mbps.  An  accompanying  First-In-First-Out 
32,768-byte  buffer  stores  Ethernet  frames  until  they  can  be  processed.  As  a  result, 
the  TRAPP-2  system  is  not  strictly  linked  to  a  clock  like  the  TRAPP-1  system. 

The  second  hardware  modihcation  is  the  memory  location  of  the  hash  list  and 
log  hie.  The  hash  list,  separate  for  each  of  the  three  protocols,  contains  a  sorted  list 
of  hashes  used  to  determine  if  a  Bit  Torrent,  SIP,  or  DNS  packet  hash  is  of  interest. 
The  log  hie  contains  all  of  the  packets  of  interest  detected  by  the  TRAPP-2  system. 
The  TRAPP-1  system  relies  on  two  sets  of  64  KB  Block  Random  Access  Memory 
(BRAM)  to  separately  store  the  hash  list  and  log  hie.  The  maximum  amount  of 
BRAM  available  on  the  TRAPP-2  system’s  PPGA  is  128  KB  per  block.  This  severely 
limits  the  maximum  hash  list  size,  which  is  explored  in  Experiment  4.  As  a  result, 
the  BRAM  architecture  is  abandoned  in  favor  of  a  512  MB  Synchronous  Dynamic 
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Random  Access  Memory  (SDRAM)  scheme  for  the  TRAPP-2  system.  SDRAM  is 
used  to  store  the  hash  list  and  log  hie  together.  Pilot  tests  reveal  an  average  increase 
of  777  CPU  cycles  in  packet  processing  time  for  the  SDRAM  scheme.  However,  the 
4096-fold  gain  in  physical  memory  address  space  at  the  cost  of  777  CPU  cycles  is 
acceptable.  This  memory  conhguration  is  also  more  realistic  for  future  conhgurations 
that  will  rely  on  larger  hash  lists.  The  pilot  test  data  for  memory  access  times  can 
be  found  in  Appendix  B.  Hardware  construction  details  for  TRAPP-2  can  be  found 
in  Appendix  C. 

3.2.2  Software  Modifications.  The  hrst  software  modihcation  adds  code  to 
detect  the  DNS  protocol.  Pilot  tests  reveal  that  the  DNS  detection  logic  requires  an 
average  of  23  CPU  cycles.  The  DNS  detection  logic  results  in  1.37%  (23/1672)  of  the 
total  packet  processing  time  for  the  packet  with  the  smallest  packet  processing  time 
(DNS-OFF-SMALL,  which  is  explained  in  Section  3.5).  The  pilot  test  data  for  the 
DNS  packet  detection  logic  can  be  found  in  Appendix  B. 

The  second  software  modihcation  involves  the  processing  of  SIP  and  DNS  pack¬ 
ets.  The  TRAPP-1  system  only  extracts  the  hrst  12  bytes  of  a  SIP  URL  For  example, 
if  the  SIP  URI  is  2001010 .1.1. 50,  the  TRAPP-1  system  extracts  2001010 .1.1.  and 
compares  it  against  the  list  of  interest.  Although  feasible,  this  logic  is  not  realistic 
because  SIP  usernames,  2001  in  this  case,  can  easily  be  changed.  The  TRAPP-2  sys¬ 
tem  does  not  extract  the  SIP  username,  2001,  in  the  example.  The  second  problem 
is  in  how  the  TRAPP-1  system  addresses  SIP  URI  domains,  or  everything  after  the  0 
symbol.  The  TRAPP- 1  system  algorithm  assumes  the  domain  is  only  seven  charac¬ 
ters  long.  As  an  improvement,  the  TRAPP-2  system  extracts  the  entire  domain  and 
is  not  limited  by  the  domain  length. 

The  hnal  software  modihcation  involves  hashing  SIP  and  DNS  domains.  For  the 
hash  lists  of  interest,  a  uniform  hash  length  is  required  for  proper  binary  searching 
of  the  hash  list.  The  variable-length  domains  of  both  SIP  and  DNS  do  not  allow 
for  a  uniform  hash  list.  As  a  result,  the  sdbm  hash  is  implemented  to  convert  the 
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variable  length  SIP  and  DNS  domains  into  a  four-byte  hash.  More  details  about  the 
sdbm  hash  can  be  found  in  Section  2.5.  Pilot  tests  reveal  that  an  average  of  86  CPU 
cycles  are  required  to  sdbm  hash  a  six  character  domain  and  1,195  CPU  cycles  are 
required  to  sdbm  hash  a  212  character  domain  name.  This  86  -  1,195  CPU  cycle 
increase  in  packet  processing  time  is  acceptable  to  create  uniform  hash  identihers  for 
the  variable-length  SIP  and  DNS  domains.  The  pilot  test  data  for  the  sdbm  hashing 
times  can  be  found  in  Appendix  B. 

3.2.3  Algorithm.  Figure  3.2  illustrates  the  TRAPP-2  algorithm  which  in¬ 
cludes  the  following  steps: 

1.  Detect  packet 

2.  Determine  if  Bit  Torrent,  SIP,  or  DNS  packet 

3.  If  BitTorrent/SIP/DNS  packet,  extract  the  payload;  else,  discard  the  packet 

4.  If  SIP  or  DNS,  sdbm  hash  the  domains 

5.  Compare  the  hash  against  the  hash  list 

6.  If  a  match  is  found  (Bit Torrent  or  SIP),  log  the  packet;  else,  drop  the  packet 

7.  If  a  match  is  not  found  (DNS),  log  the  packet;  else,  drop  the  packet 

For  Bit  Torrent  packets,  the  system  detects  a  Bit  Torrent  handshake  packet,  ex¬ 
tracts  the  hrst  four  bytes  of  the  20-byte  SHA-1  hash,  compares  the  hash  against  a 
blacklist  containing  the  hrst  four  bytes  of  suspicious  hashes,  and  logs  it  if  the  hash  is 
on  the  blacklist.  A  Bit  Torrent  packet  is  dehned  as  a  TCP  packet  with  the  hrst  four 
bytes  of  the  payload  being  0x13426974  (“<13>Bit”). 

For  SIP  packets,  the  system  detects  a  SIP  INVITE  or  BYE  packet,  extracts  the 
entire  domain  from  both  the  To :  and  From :  portion  of  the  SIP  URI,  sdbm  hashes  both 
the  To :  and  From:  domains  to  create  two  unique  hashes,  compares  the  hashes  against 
a  blacklist  containing  the  suspicious  hashes  (each  four  bytes  in  length),  and  logs  it  if 
either  the  To:  or  From:  hashes  are  on  the  blacklist.  A  SIP  INVITE  packet  is  dehned 


36 


as  a  UDP  packet  with  the  hrst  four  bytes  of  the  UDP  payload  being  “INVI” .  A  SIP 
BYE  packet  is  dehned  as  a  UDP  packet  with  the  hrst  four  bytes  of  the  UDP  payload 
being  “BYE  It  is  possible  for  a  SIP  packet  to  have  the  To:  and  From:  domains  be 
the  same.  This  occurs  if  both  sender  and  receiver  are  communicating  through  the 
same  SIP  proxy  server.  Refer  to  Section  2.1.2  for  more  information  about  the  SIP 
packet. 


Figure  3.2:  Packet  Data  Flow  in  the  TRacking  and  Analysis  for  Peer-to-Peer  2 

System. 
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For  DNS  packets,  the  system  detects  a  DNS  request,  extracts  the  entire  domain, 
sdbm  hashes  the  domain  to  create  a  four-byte  unique  hash,  compares  the  hash  against 
a  whitelist  of  approved  domain  hashes,  and  logs  it  if  it  is  not  on  the  DNS  whitelist. 
A  DNS  request  is  dehned  as  a  UDP  packet  with  a  destination  port  of  53.  DNS  zone 
transfers,  performed  over  TCP  port  53,  are  not  included  because  they  are  not  capable 
of  exhitrating  data. 

3.3  System  Boundaries 

The  System  Under  Test  (SUT)  for  this  research  is  the  TRAPP-2  system.  The 
SUT  block  diagram  is  illustrated  in  Figure  3.3.  The  SUT  components  include: 
TRAPP-2  software,  FPGA  and  board,  PowerPC  Processor,  System  Timer,  Ether¬ 
net  Controller,  two  512  MB  SDRAM  modules,  and  a  serial  RS232  controller.  The 
Component  Under  Test  (CUT)  is  the  TRAPP-2  software. 

The  workload  parameters  include  the  type  of  Bit  Torrent,  SIP,  DNS,  and  non- 
Bit  Torrent /SIP /DNS  packet,  as  well  as  a  network  load.  The  single  system  parameter 
is  the  hash  list  size.  The  metrics  include  the  packet  processing  time  and  the  probability 
of  packet  intercept. 

Hash  List  Size 


BitTorrent  Packet  Type 
SIP  Packet  Type 
DNS  Packet  Type 
Non-  BT/SIP/DNS 
Packet  Type 

Network  Load 


TRAPP-2 


TRAPP-2 

Software 

(CUT) 


Ethernet 

Controller 


PowerPC 

Processor 


Two  512  MB 
SDRAM 
Modules 


FPGA& 

Board 


System 

Timer 


RS232 

Controller 


Packet 

Processing  Time 


Probability  of 
Packet  Intercept 


Figure  3.3:  The  TRacking  and  Analysis  for  Peer-to-Peer  2  System  Under  Test. 
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3-4  System  Services 

The  TRAPP-2  system  assists  network  administrators,  law  enforcement  officials, 
and  intelligence  agencies  in  detecting  and  tracking  traffic  of  interest.  The  system 
resides  between  a  local  area  network  and  the  Internet  gateway  and  receives  all  the 
traffic  flowing  through  the  gateway.  Figure  3.2  illustrates  the  functionality  of  the 
TRAPP-2  system. 

The  system  is  successful  when  the  following  steps  are  all  completed: 

1.  A  Bit  Torrent  handshake  packet,  a  SIP  INVITE  or  BYE  packet,  or  a  DNS  request 
is  detected. 

2.  The  respective  hie  info  hash,  SIP  URIs,  or  DNS  domain  are  extracted. 

3.  (SIP/DNS  only)  The  domain  is  sdbm  hashed. 

4.  The  hash  is  compared  against  separate  lists  of  interest  for  Bit  Torrent,  SIP,  and 
DNS  packets. 

5.  If  a  match  is  found  for  the  Bit  Torrent  and  SIP  packets,  the  packet  contents 
are  written  to  a  Wireshark-compatible  log  hie.  For  DNS,  if  the  DNS  hash  is 
not  found  on  the  DNS  hash  whitelist,  the  packet  is  written  to  a  Wireshark- 
compatible  log  hie. 

A  system  service  failure  occurs  when: 

1.  The  system  does  not  detect  a  packet  of  interest  when  one  is  present. 

2.  A  packet  of  interest  is  detected  but  the  hie  info  hash,  SIP  URIs,  or  DNS  domain 
are  not  extracted. 

3.  The  packet  information  is  not  written  to  the  log  hie. 

As  with  the  TRAPP- 1  system,  false  positives  are  not  considered.  The  assump¬ 
tion  is  that  an  administrator  will  review  the  contents  of  the  log  hie  to  validate  the 
packets  of  interest  [Sch09].  For  Bit  Torrent,  SIP,  and  DNS,  a  4-byte  hash  is  compared 
against  the  hash  list  resulting  in  a  probability  of  collision  of  1  in  4,294,967,296  (2^^). 
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The  TRAPP-2  system  can  be  configured  to  compare  larger  hashes  to  decrease  false 
positives  and  the  probability  of  collision. 

3. 5  Workload 

The  workload  for  the  TRAPP-2  SUT  consists  of  Bit  Torrent /SIP /DNS  packets,  a 
non-Bit Torrent /SIP /DNS  packet,  and  a  network  load.  To  reduce  the  number  of  packet 
type  factors,  specific  packets  are  selected  for  the  Bit  Torrent /SIP/DNS  workload.  Each 
protocol  has  a  worst-  and  best-case  packet  for  packets  of  interest,  and  only  a  worst- 
case  packet  for  uninteresting  packets.  This  allows  a  range  of  packet  processing  times 
to  be  established  by  using  the  extremes  for  each  protocol. 

Additionally,  it  is  important  to  generate  packets  on  the  network  that  are  Bit- 
Torrent,  SIP,  or  DNS  packets,  but  not  of  interest.  These  packets  ensure  that  the 
system  detects  the  three  protocols,  but  the  hash  is  not  of  interest.  For  uninteresting 
packets,  only  the  worst-case  scenario  packet  is  selected. 

For  each  of  the  protocols,  a  weighted  system  is  used  to  select  the  worst-  and  best- 
case  scenarios  for  each  packet  type.  Certain  characteristics  of  each  packet  determine 
the  effectiveness  of  the  TRAPP-2  system.  Packets  acquire  points  for  having  certain 
characteristics.  For  each  type  of  protocol,  the  packets  with  the  least  amount  of  points 
(best-case)  and  most  amount  of  points  (worst-case)  are  used.  The  points  are  further 
explained  under  each  characteristic.  The  characteristics  used  for  packet  selection 
include: 

1.  Hash  is  on/off  the  hash  list 

2.  The  location  of  the  hash  on  the  hash  list 

3.  (SIP/DNS  only)  The  size  of  the  packet  in  bytes 

4.  (SIP/DNS  only)  The  length  of  the  domain  required  to  sdbm  hash 
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3.5.1  Packet  Workload  Characteristics. 


3. 5. 1.1  Hash  Is  On/ Off  the  Hash  List.  If  a  Bit  Torrent  or  SIP  packet 
has  a  hash  on  the  blacklist,  then  it  must  be  logged,  which  requires  additional  CPU 
cycles.  If  a  DNS  packet  does  not  have  a  hash  on  the  whitelist,  then  it  must  be  logged, 
which  requires  additional  CPU  cycles.  For  the  weighted  system,  a  packet  gets  1  point 
for  having  a  hash  on  the  hash  list  (for  BitTorrent  and  SIP)  or  1  point  for  having  a 
hash  off  the  hash  list  (for  DNS). 

3. 5. 1.2  Location  of  Hash  on  the  Hash  List.  The  location  of  the  hash 
on  the  hash  list  affects  the  number  of  CPU  cycles  used  by  the  binary  search  algorithm. 
If  the  hash  is  in  the  middle  of  the  list,  the  binary  search  algorithm  hnds  it  on  the  hrst 
try,  thus  requiring  the  fewest  CPU  cycles.  If  the  hash  is  at  the  end  of  the  list,  or  off 
the  list,  the  algorithm  requires  the  most  comparisons,  and  thus  more  CPU  cycles,  to 
locate  the  hash.  For  the  weighted  system,  a  packet  gets  1  point  if  its  hash  is  at  worst 
possible  location  on  the  hash  list  (for  BitTorrent  and  SIP)  or  1  point  if  it  is  off  the 
list  (for  DNS). 

3.5. 1.3  SIP /DNS  Only:  Size  of  the  Packet.  Since  the  TRAPP-2 
system  must  copy  the  entire  packet  into  a  software  buffer,  the  size  of  the  packet  affects 
how  quickly  this  is  accomplished.  Pilot  tests  reveal  that  67-byte  packets  averaged  999 
CPU  cycles  and  1500-byte  packets  averaged  18,112  CPU  cycles.  Thus,  the  size  of  the 
packet  impacts  the  amount  of  CPU  cycles  required  to  process  it.  For  the  weighted 
system,  a  packet  gets  1  point  for  being  the  largest.  BitTorrent  handshake  packets 
do  not  exceed  122  bytes  so  only  one  packet  size  is  used.  The  pilot  test  data  for  the 
packet  size  transfer  times  can  be  found  in  Appendix  B. 

3. 5. 1.4  SIP/DNS  Only:  Length  of  Domain.  Since  the  sdbm  hashing 
function  is  utilized  in  the  TRAPP-2  system,  the  domain  length  of  SIP  URIs  and  DNS 
requests  affect  the  number  of  CPU  cycles  required  to  generate  the  four-byte  hash. 
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Refer  to  Section  3.2.2  for  the  specific  numbers.  For  the  weighted  system,  a  SIP/DNS 
packet  gets  1  point  if  it  has  the  largest  possible  domain. 

3.5.2  BitTorrent  Workload.  The  different  possible  types  of  Bit  Torrent  pack¬ 
ets  are  illustrated  in  Figure  3.4.  The  hierarchy  is  read  from  left  to  right.  One  type  of 
packet,  for  example,  is  a  BitTorrent  packet  with  a  hash  on  the  hash  list,  with  a  hash 
located  in  the  worst  hash  list  location.  This  can  be  abbreviated  as  BT-ON-WORST. 
Unlike  SIP  or  DNS  packets,  the  size  of  the  BitTorrent  handshake  packet  does  not 
exceed  122  bytes,  so  the  packet  size  characteristic  is  eliminated.  See  Section  2.1.1  for 
more  details  about  the  contents  of  the  BitTorrent  handshake  packet. 


Figure  3.4:  BitTorrent  Packet  Type  Hierarchy  for  the  TRacking  and  Analysis  for 
Peer-to-Peer  2  System. 

Using  the  weighted  packet  system,  the  scores  for  each  type  of  BitTorrent  packet 
are  in  Table  3.1,  with  the  selected  BitTorrent  workload  packets  in  bold.  In  the  case 
of  BitTorrent  packets  on  the  list,  the  best-case  scenario  packet  is  the  BT-ON-BEST, 
with  a  score  of  1.  The  worst-case  scenario  packet  is  the  BT-ON-WORST,  with  a  score 
of  2.  For  BitTorrent  packets  not  on  the  list,  the  worst-case  scenario  packet  is  BT- 
OFF  with  a  score  of  0.  So,  in  the  case  of  BitTorrent  packets,  all  three  combinations 
of  BitTorrent  packets  are  used. 
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Table  3.1;  Bit  Torrent  Packet  Weights  for  the  TRacking  and  Analysis  for  Peer-to- 
Peer  2  System. 


Protocol 

On/Off  Hash  List 

Best/Worst  Hash  Location 

Total 

BT 

ON 

1 

BEST 

0 

1 

ON 

1 

WORST 
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2 

OFF 

0 

- 

0 

0 

BOLD  =  Selected  BitTorrent  Workload  Packet 


To  summarize,  the  three  types  of  BitTorrent  packets  used  are: 


1.  BT-ON-BEST:  A  122-byte  BitTorrent  packet  with  a  hash  on  the  hash  list  at 
the  best  location  (middle  of  the  hash  list). 

2.  BT-ON-WORST:  A  122-byte  BitTorrent  packet  with  a  hash  on  the  hash  list  at 
the  worst  location  (beginning  of  the  hash  list). 

3.  BT-OFF;  A  122-byte  BitTorrent  packet  with  a  hash  not  on  the  hash  list. 
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The  contents  of  BT-OFF: 
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3.5.3  SIP  Workload.  The  different  SIP  packet  type  combinations  are  illus¬ 
trated  in  Figure  3.5.  The  hierarchy  is  read  from  left  to  right.  One  type  of  packet, 
for  example,  is  a  SIP  INVITE  packet  with  a  hash  on  the  hash  list,  small  in  byte 
size,  with  a  hash  located  in  the  best  hash  list  location.  This  can  be  abbreviated  as 
SIP-INVITE-ON-SMALL-BEST. 


Figure  3.5:  Session  Initiation  Protocol  Packet  Type  Hierarchy  for  the  TRacking 

and  Analysis  for  Peer-to-Peer  2  System. 


44 


Using  the  weighted  packet  system,  the  scores  for  each  type  of  SIP  INVITE 
packet  are  in  Table  3.2,  with  the  selected  SIP  INVITE  workload  packets  in  bold. 
In  the  case  of  SIP  INVITE  packets  on  the  list,  the  best-case  scenario  packet  is  the 
SIP-INVITE-ON-SMALL-BEST,  with  a  score  of  1.  The  worst-case  scenario  for  a  SIP 
INVITE  packet  is  the  SIP-INVITE-ON-LARGE- WORST,  with  a  score  of  3.  Eor  SIP 
INVITE  packets  not  on  the  list,  the  worst-case  scenario  packet  is  the  SIP-INVITE- 
OFF-LARGE  with  a  score  of  1. 


Table  3.2:  Session  Initiation  Protocol  INVITE  Packet  Weights  for  the  TRacking 
and  Analysis  for  Peer-to-Peer  2  System. 
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Hash  List 

Packet  Size 

Best /Worst 

Hash  Location 

Total 

SIP 

INV 

ON 

1 

SMALL 

0 

BEST 

0 

1 

INV 

ON 

I 

SMALL 

0 

WORST 

I 

2 

INV 

ON 

I 

LARGE 

I 

BEST 

0 

2 

INV 

ON 

1 

LARGE 

1 

WORST 

1 

3 

INV 

OEE 

0 

SMALL 

0 

- 

- 

0 

INV 

OFF 

0 

LARGE 

1 

- 

- 

1 

BOLD  =  Selected  SIP  INVITE  Workload  Packet 


As  a  reminder,  the  TRAPP-2  system  is  looking  for  both  SIP  INVITE  and  SIP 
BYE  packets.  Using  the  weighted  packet  system  for  SIP  BYE  packets,  the  scores  for 
each  type  are  in  Table  3.3,  with  the  selected  SIP  BYE  workload  packets  in  bold.  The 
best-case  scenario  for  SIP  BYE  packets  is  the  SIP-BYE-ON-SMALL-BEST,  with  a 
score  of  1.  The  worst-case  scenario  for  SIP  BYE  packets  is  the  SIP-BYE-ON-LARGE- 
WORST,  with  a  score  of  3.  The  SIP  BYE  packet  with  a  URI  not  on  the  list  (OFF) 
is  omitted  for  two  reasons.  The  hrst  is  that  from  the  viewpoint  of  the  TRAPP-2 
software,  the  packets  are  the  same.  Secondly,  the  SIP  INVITE  will  take  longer  to 
process  because  of  the  larger  packet  size  and  thus  represents  the  worst-case  between 
the  two. 
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Table  3.3:  Session  Initiation  Protocol  BYE  Packet  Weights  for  the  TRacking  and 
Analysis  for  Peer-to-Peer  2  System. 


Protocol 

INV/BYE 

On/Off 

Hash  List 

Packet  Size 

Best /Worst 

Hash  Location 

Total 

SIP 

BYE 

ON 

1 

SMALL 

0 

BEST 

0 

1 

BYE 

ON 

1 

SMALL 

0 

WORST 

1 

2 

BYE 

ON 

1 

LARGE 

1 

BEST 

0 

2 

BYE 

ON 

1 

LARGE 

1 

WORST 

1 

3 

BOLD  =  Selected  SIP  BYE  Workload  Packet 


To  summarize,  the  five  types  of  SIP  packets  used  are: 

1.  SIP-INVITE-ON-SMALL-BEST:  A  932-byte  SIP  INVITE  packet  with  a  hash 
on  the  hash  list  at  the  best  location. 

2.  SIP-INVITE-ON-LARGE-WORST:  A  1500-byte  SIP  INVITE  packet  with  a 
hash  on  the  hash  list  at  the  worst  location. 

3.  SIP-INVITE-OFF-LARGE:  A  1500-byte  SIP  INVITE  packet  with  a  hash  not 
on  the  hash  list. 

4.  SIP-BYE-ON-SMALL-BEST:  A  479-byte  SIP  BYE  packet  with  a  hash  on  the 
hash  list  at  the  best  location. 

5.  SIP-BYE-ON-LARGE- WORST:  A  1040-byte  SIP  BYE  packet  with  a  hash  on 
the  hash  list  at  the  worst  location. 


3.5.3. 1  SIP  Workload  Packets.  Five  types  of  SIP  packets  are  used. 
The  length  of  the  domain  affects  the  size  of  the  SIP  packet.  For  small  packets,  the 
domain  192.168.3.110  is  used.  For  large  packets,  the  artihcially  created  domain 
below  is  used: 


abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnopqrstuvwxyz . abcdef gh 
i jklmnopqrstuvwxyz . abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnop 
qrstuvwxyz . abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnopqrstuvwx 
yz . com . localhost 
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The  contents  of  SIP-INVITE-ON-SMALL-BEST: 


INVITE  sip:2000@192. 168.3. 110  SIP/2.0 

Via:  SIP/2. 0/UDP  192.168.1.3:39966;branch=z9hG4bK-d8754z- 
be20982f  bb7f  b76f-l— d8754z- ;  rport 
Max-Forwards:  70 

Contact :  <sip : 20010192 . 168 .1.3: 39966> 

To :  "2000"<sip : 20000192 .168.3. 110> 

From:  "Beta"<sip : 20010192 . 168 . 3 . 110> ; tag=5c4c0451 
Call- ID :  MGIwNTdiMDI5NzU2YzhmMDEzYzMxMzU2Y2QzOWRhODQ . 

CSeq:  1  INVITE 

Allow:  INVITE,  ACK,  CANCEL,  OPTIONS,  BYE,  REFER,  NOTIFY, 

MESSAGE,  SUBSCRIBE,  INFO 
Content-Type:  application/sdp 
User-Agent:  X-Lite  release  1104o  stamp  56125 
Content-Length:  360 

The  contents  of  SIP-INVITE-ON-LARGE- WORST: 

INVITE  sip : 2OO10abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnopqrstuvw 
xyz . abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnopqrstuvwxyz . abcdef gh 
i jklmnopqrstuvwxyz . abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnopqrst 
uvwxyz.com.localhost  SIP/2.0 

Via:  SIP/2. 0/UDP  192.168.1.2:57538;branch=z9hG4bK-d8754z- 
al60bel3fe074026-l—d8754z-;  rport 
Max-Forwards:  70 

Contact :  <sip : 20000192 . 168 .1.2: 57538> 

To :  "2001"<sip : 2OO10abcdef ghijklmnopqrstuvwxyz . abcdef ghi jklmno 
pqrstuvwxyz . abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnopqrstuvw 
xyz . abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnopqrstuvwxyz . abed 
ef ghi jklmnopqrstuvwxyz . com. localhost> 

From:  "Alpha"<sip : 2OOO0abcdef ghi jklmnopqrstuvwxyz . abcdef ghijkl 
mnopqrstuvwxyz . abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnopqrst 
uvwxyz . abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnopqrstuvwxyz . a 
bedef ghi jklmnopqrstuvwxyz . com . localhost> ; tag=8356dl39 
Call-ID :  M2UwNmQ3MDVlNj cOMzA5DDE4ZmFlMWU2ZmU2MzhiMWI . 

CSeq:  1  INVITE 

Allow:  INVITE,  ACK,  CANCEL,  OPTIONS,  BYE,  REFER,  NOTIFY,  MESSAGE, 
SUBSCRIBE,  INFO 
Content-Type:  application/sdp 
User-Agent:  X-Lite  release  1104o  stamp  56125 
Content-Length:  360 
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The  contents  of  SIP-INVITE-OFF-LARGE  (note  that  1234  replaced  abed  for 
the  hrst  four  characters  of  the  domain): 

INVITE  sip : 2001@1234ef ghi jkimnopqrstuvwxyz . abedef ghi jkimnopqrstuvw 
xyz . abedef ghi jkimnopqrstuvwxyz . abedef ghi jkimnopqrstuvwxyz . abedef gh 
i jkimnopqrstuvwxyz . abedef ghi jkimnopqrstuvwxyz . abedef ghi jklmnopqrst 
uvwxyz.eom.loealhost  SIP/2.0 

Via:  SIP/2. 0/UDP  192.168.1.2:57538;braneh=z9hG4bK-d8754z- 
al60bel3fe074026-l— d8754z-;rport 
Max-Forwards:  70 

Contaet :  <sip : 20000192 . 168 .1.2: 57538> 

To :  "2001"<sip : 200101234ef ghijklmnopqrstuvwxyz . abedef ghi jklmno 
pqrstuvwxyz . abedef ghi jkimnopqrstuvwxyz . abedef ghi jkimnopqrstuvw 
xyz . abedef ghi jkimnopqrstuvwxyz . abedef ghi jkimnopqrstuvwxyz . abed 
ef ghi jkimnopqrstuvwxyz . eom. loealhost> 

From:  "Alpha"<sip : 200001234efghijklmnopqrstuvwxyz . abedef ghijkl 
mnopqrstuvwxyz . abedef ghi jkimnopqrstuvwxyz . abedef ghi jklmnopqrst 
uvwxyz . abedef ghi jkimnopqrstuvwxyz . abedef ghi jkimnopqrstuvwxyz . a 
bedef ghi jkimnopqrstuvwxyz . eom . loealhost> ; tag=8356dl39 
Call-ID :  M2UwNmQ3MDVlNj eOMzA5DDE4ZmFlMWU2ZmU2MzhiMWI . 

CSeq:  1  INVITE 

Allow:  INVITE,  ACK,  CANCEL,  OPTIONS,  BYE,  REFER,  NOTIFY,  MESSAGE, 
SUBSCRIBE,  INFO 
Content-Type:  applieation/sdp 
User-Agent:  X-Lite  release  1104o  stamp  56125 
Content-Length:  360 

The  contents  of  SIP-BYE-ON-SMALL-BEST: 

BYE  sip:20010192. 168. 1.3:39966  SIP/2.0 

Via:  SIP/2. 0/UDP  192. 168.3. 110: 5060; branch=z9hG4bK14b4f 667; rport 
Max-Forwards:  70 

From:  "2000"<sip : 20000192 . 168 . 3 . 110> ; tag=as758a70a9 
To :  "Beta"<sip : 20010192 .168.3. 110> ; tag=5c4c0451 
Call-ID :  MGIwNTdiMDI5NzU2YzhmMDEzYzMxMzU2Y2QzOWRhODQ . 

CSeq:  102  BYE 

User-Agent:  Asterisk  PBX  1 . 6 . 0 . 10-FONCORE-r40 
X-Asterisk-HangupCause :  Normal  Clearing 
X-Asterisk-HangupCauseCode :  16 
Content-Length:  0 
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The  contents  of  SIP-BYE-ON-LARGE- WORST: 


BYE  sip:2001@192.168.1.5  SIP/2.0 

Via:  SIP/2. 0/UDP  192 . 168 . 1 . 2 : 57538 ;branch=z9hG4bK-d8754z- 

014f  c825e962763e-l - d8754z- ; rport 

Max-Forwards:  70 

Contact :  <sip : 20000192 . 168 .1.2: 57538> 

To :  "2001"<sip : 2001@abcdef ghijklmnopqrstuvwxyz . abcdefghijklmno 
pqrstuvwxyz . abcdef ghijklmnopqrstuvwxyz . abcdef ghi jklmnopqrstuvw 
xyz . abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnopqrstuvwxyz . abed 
ef ghijklmnopqrstuvwxyz . com. localhost> ; tag=as22d800eb 
From:  "Alpha"<sip : 2000@abcdef ghi jklmnopqrstuvwxyz . abcdef ghijkl 
mnopqrstuvwxyz . abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnopqrst 
uvwxyz . abcdef ghi jklmnopqrstuvwxyz . abcdef ghi jklmnopqrstuvwxyz . a 
bedef ghi jklmnopqrstuvwxyz . com . localhost> ; tag=8356dl39 
Call-ID :  M2UwNmQ3MDVlNj cOMzA5DDE4ZmFlMWU2ZmU2MzhiMWI . 

CSeq:  3  BYE 

User-Agent:  X-Lite  release  1104o  stamp  56125 

Authorization:  Digest  username="2000" ,realm="asterisk" ,nonce="669dc6aa" , 
uri="sip : 20010192 .168.1.5", response="91d3092c48e35c3275c4f 2f 47e57336d" , 
algor ithm=MD5 

Reason:  SIP;description="User  Hung  Up" 

Content-Length:  0 


3.5.4  DNS  Workload.  The  different  possible  types  of  DNS  packets  are 
illustrated  in  Figure  3.6.  The  hierarchy  is  read  from  left  to  right.  One  type  of  packet, 
for  example,  is  a  DNS  packet  with  a  hash  on  the  whitelist,  large  in  byte  size,  with 
a  hash  located  in  the  worst  location.  This  can  be  abbreviated  as  DNS-ON-LARGE- 
WORST. 
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Figure  3.6:  Domain  Name  System  Packet  Type  Hierarchy  for  the  TRacking  and 

Analysis  for  Peer-to-Peer  2  System. 

Using  the  weighted  packet  system,  the  scores  for  each  type  of  DNS  packet  are 
in  Table  3.4,  with  the  selected  DNS  workload  packets  in  bold.  For  DNS  packets 
with  hashes  not  on  the  whitelist  (the  ones  of  interest),  the  best-case  scenario  is  the 
DNS-OFF-SMALL  packet,  with  a  score  of  1.  The  worst-case  scenario  packet  is  the 
DNS-OFF-LARGE  packet,  with  a  score  of  2.  For  valid  DNS  domains  on  the  whitelist, 
the  worst-case  scenario  is  the  DNS-ON-LARG E-WORST  packet,  with  a  score  of  2. 


Table  3.4:  Domain  Name  System  Packet  Weights  for  the  TRacking  and  Analysis 
for  Peer-to-Peer  2  System. 


Protocol 

On/ Off  hash  list 

Packet  Size 

Best/Worst  hash  location 

Total 

DNS 

OFF 

1 

SMALL 

0 

- 

1 

1 

OFF 

1 

LARGE 

1 

- 

1 

2 

ON 

0 

SMALL 

0 

BEST 

0 

0 

ON 

0 

SMALL 

0 

WORST 

1 

1 

ON 

0 

LARGE 

1 

BEST 

0 

1 

ON 

0 

LARGE 

1 

WORST 

1 

2 

BOLD  =  Selected  DNS  Workload  Packet 
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To  summarize,  the  three  types  of  DNS  packets  used  are: 


1.  DNS-OFF-SMALL:  A  67-byte  DNS  request  packet  with  a  hash  not  on  the  hash 
list 

2.  DNS-OFF-LARGE:  A  190-byte  DNS  request  packet  not  on  the  hash  list.  The 
packet  is  generated  using  Iodine  [Kry09],  a  DNS  exhltration  tool.  The  authen¬ 
ticity  of  the  malicious  packet  is  selected  over  a  larger  actual  byte  size,  which 
can  be  achieved  by  increasing  the  domain  length. 

3.  DNS-ON-LARGE-WORST:  A  190-byte  DNS  request  packet  with  a  hash  on  the 
hash  list  in  the  worst  location 


3.5.4- 1  DNS  Workload  Packets.  Three  types  of  DNS  packets  are  used. 
The  contents  of  DNS-OFF-SMALL: 
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The  contents  of  DNS-OFF-LARGE: 
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The  contents  of  DNS-ON-LARGE- WORST: 
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3.5.5  Non-BitTorrent/SIP/DNS  Workload.  The  non-Bit Torrent /SIP /DNS 
packet  used  is  an  HTTP  packet.  Its  signature  does  not  match  that  of  a  Bit  Torrent, 
SIP,  or  DNS  packet.  The  HTTP  packet  is  389  bytes  in  size.  The  average  size  packet  of 
an  hour-long  Wireshark  network  capture  from  a  lab  network  with  multiple  computers 
accessing  the  Internet  is  389  bytes.  The  contents  of  the  HTTP  packet: 
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3.5.6  Network  Load.  For  Experiment  3,  a  network  load  consisting  of  non- 
Bit Torrent /SIP/DNS  traffic  is  added  to  the  system  using  the  Linux  pktgen  util¬ 
ity  [FoulO].  By  adding  the  load,  the  resulting  minimum  network  utilization  is  ap¬ 
proximately  20%  and  is  increased  at  10%  intervals  up  to  the  maximum  acheivable 
rate  of  93.7%  (equivalent  to  937  Mbps).  Table  3.5  summarizes  the  different  network 
utilizations  achieved  as  a  result  of  adding  the  Linux  pktgen  utility  load.  In  Experi¬ 
ment  3,  the  network  utilization  is  measured  using  variables  within  the  Linux  pktgen 
utility,  described  in  Section  3. 6. 3. 2. 


Table  3.5:  Network  Utilizations  Due  to  the  Linux  pktgen  Utility  Load  in  the  TRack- 
ing  and  Analysis  for  Peer-to-Peer  2  System. 


Mbps 

Network  Utilization  % 
(Mbps/1000) 

204 

20.4% 

301 

30.1% 

408 

40.8% 

498 

49.8% 

602 

60.2% 

714 

71.4% 

818 

81.8% 

937 

93.7% 

3.6  Performance  Metrics 

The  two  performance  metrics  used  to  evaluate  the  effectiveness  of  the  TRAPP- 
2  system  are  packet  processing  time  and  the  probability  of  packet  intercept.  This 
section  also  describes  how  the  Network  Utilization  is  measured  for  the  experiments. 
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3.6.1  Packet  Processing  Time.  The  first  metric  is  the  packet  processing 
time,  which  measures  the  CPU  cycles  used  to  process  packets.  The  PowerPC’s  System 
Timer  timestamp  function  is  used  for  this.  The  packet  processing  time  begins  when 
a  packet  arrives  in  the  Ethernet  controller.  Packet  processing  time  ends  immediately 
after  processing  of  the  packet  has  completed.  This  metric  is  important  because  packet 
processing  time  must  be  minimized  to  check  every  packet  traversing  the  network. 
Measuring  the  packet  processing  time  also  gives  insight  into  how  the  TRAPP-2  system 
responds  to  different  packet  type  characteristics  (Experiment  1)  and  hash  list  sizes 
(Experiment  4). 

3.6.2  Probability  of  Packet  Intercept.  The  second  metric  is  the  probability 
of  packet  intercept.  This  is  calculated  by  determining  if  a  packet  of  interest  is  cap¬ 
tured  and  successfully  recorded  to  the  log  hie.  When  measuring  the  probability  of 
packet  intercept,  the  network  utilization  of  the  system  is  also  measured.  Experiment 
2  measures  the  probability  of  packet  intercept  while  hooding  the  TRAPP-2  system 
with  protocol-under-test  (BitTorrent,  SIP,  or  DNS)  traffic.  The  Linux  utility,  tcpre- 
play,  is  used  to  send  a  previously  captured  .pcap  hie  containing  400  packets  of  interest 
as  quickly  as  possible  [TcplO].  Experiment  3  measures  the  probability  of  packet  in¬ 
tercept  of  packets  of  interest  while  adding  a  non-BitTorrent/SIP/DNS  traffic  load  to 
the  TRAPP-2  system.  The  load  is  generated  using  the  Linux  pktgen  utility. 

3.6.3  Network  Utilization.  The  network  utilization  is  the  total  amount 
of  traffic  entering  the  TRAPP-2  system.  For  Experiment  1  and  Experiment  4,  the 
network  utilization  is  limited  to  single  packets  injected  into  the  system,  and  is  thus 
virtually  zero.  For  Experiment  2,  the  network  utilization  varies  with  the  type  of 
protocol-under-test  packet  being  hooded  into  the  system.  In  Experiment  2,  the  net¬ 
work  utilization  is  measured  using  Wireshark.  For  Experiment  3,  the  network  utiliza¬ 
tion  varies  with  the  type  of  load  generated  by  the  Linux  pktgen  utility.  In  Experiment 
3,  the  network  utilization  is  measured  using  variables  within  the  Linux  pktgen  utility. 
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3.6.3. 1  Measuring  Network  Utilization  Using  Wireshark.  For  Exper¬ 
iment  2,  the  load  is  measured  using  the  Wireshark  laptop  connected  to  the  gigabit 
switch’s  other  Switched  Port  Analyzer  (SPAN)  port.  When  each  test  has  concluded, 
the  network  utilization  is  measured  by  selecting  the  Statistics  ->  Summary  menu 
option  and  recording  the  Avg.  MBit/sec  from  the  Displayed  column.  This  is  as¬ 
sumed  to  be  the  minimum  network  utilization. 

3. 6. 3. 2  Measuring  the  Network  Utilization  Using  the  Linux  pktgen  Utility 
Variables.  For  Experiment  3,  the  Linux  pktgen  utility  generates  packets  faster  than 
Wireshark  can  process.  In  response  to  Wireshark’s  shortfall,  an  alternative  method  to 
measure  the  network  utilization  is  necessary.  To  accomplish  this,  two  variables  must 
be  determined  to  calculate  the  network  utilization  rate  of  megabits  per  second.  The 
hrst  is  the  number  of  bits  generated  on  the  network  and  the  second  is  the  amount  of 
time  elapsed  to  send  those  bits. 

The  Linux  pktgen  utility  is  a  Bourne  Again  SHell  (BASH)  script  that  runs  in  a 
terminal.  The  Linux  pktgen  utility  allows  conhguration  of  the  packet  size,  number  of 
packets,  and  delay.  The  number  of  packets  and  packet  size  remain  static,  at  6,000,000 
packets  and  1,500  bytes,  respectively.  The  delay  variable  is  modihed  to  achieve  the 
different  network  utilization  percentages. 

A  timestamp  function  within  the  BASH  scripting  language  is  used  to  record  the 
number  of  nanoseconds  since  January  1,  1970.  This  timestamp  function  is  taken  right 
before  the  Linux  pktgen  utility  begins  and  immediately  after  completion.  As  a  result, 
the  total  amount  of  time  required  to  send  the  6,000,000  packets  is  known.  Since  both 
variables  are  known,  the  megabits  per  second  network  utilization  can  be  calculated 
using  the  formula: 


Network  Utilization 


Packets  x  Packet  Size  {Bytes)  x  (^m^)  x 
Elapsed  Time 
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Where  Packets  is  6,000,000,  Packet  Size  is  1,500  and  Elapsed  Time  is  measured 
using  the  BASH  timestamp  function.  A  delay  variable  within  the  Linux  pktgen  util¬ 
ity  BASH  script  is  modihed  to  throttle  this  rate  to  achieve  the  decreased  network 
utilizations. 

3.7  System  Parameters 

The  single  TRAPP-2  system  parameter  is  the  hash  list  size.  For  Experiments 
1,  2,  and  3,  a  hash  list  size  of  1000  is  used.  For  Experiment  4,  the  hash  list  size  is 
doubled  from  2,000  up  to  131,072,000  unique  hash  items.  This  results  in  17  different 
hash  list  sizes.  The  hash  list  with  131,072,000  items  is  500  MB  in  size,  which  is  97.65% 
of  the  available  SDRAM  memory.  100%  of  the  memory  is  not  used  because  the  same 
memory  space  is  used  to  store  the  log  hie. 

The  TRAPP-2  workload  parameters  include: 

1.  Bit  Torrent  Packet  Types:  There  are  three  types  of  Bit  Torrent  packet  types. 
They  include  BT-ON-BEST,  BT-ON- WORST,  and  BT-OFF. 

2.  SIP  Packet  Types:  There  are  hve  types  of  SIP  packet  types.  They  include  SIP- 
INVITE-ON-SMALL-BEST,  SIP-INVITE-ON-LARGE- WORST, 
SIP-INVITE-OFF-LARGE,  SIP-BYE-ON-SMALL-BEST,  and  SIP-BYE-ON- 
LARGE- WORST. 

3.  DNS  Packet  Types:  There  are  three  types  of  DNS  packet  types.  They  include 
DNS-OFF-SMALL,  DNS-OFF-LARGE,  and  DNS-ON-LARGE- WORST. 

4.  Non-Bit Torrent/SIP/DNS  Packet:  This  is  the  389-byte  HTTP  packet. 

5.  Network  Load:  The  additional  network  traffic  added  to  the  system  using  the 
Linux  pktgen  utility.  An  additional  traffic  load  is  only  added  in  Experiment  3. 

3.8  Factors 

For  Experiments  1,  2,  and  3,  the  TRAPP-2  software  is  loaded  onto  the  FPGA 
board.  The  FPGA’s  Ethernet  controller  is  conhgured  to  run  at  1000  Mbps,  and  the 
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list  of  interest  size  is  1000  entries.  Experiment  1  calculates  the  packet  processing  time 
of  BitTorrent,  SIP,  DNS,  and  non-Bit Torrent /SIP/DNS  (the  HTTP  packet)  packets. 
Experiment  2  determines  the  probability  of  packet  intercept  for  a  flood  (400  packets) 
of  protocol-under-test  (BitTorrent,  SIP,  or  DNS)  traffic.  The  four  packets  selected 
are  the  worst-case  for  BitTorrent,  SIP  INVITE,  SIP  BYE,  and  DNS.  Realistically, 
the  TRAPP-2  system  will  not  see  the  same  packet  sent  as  quickly  as  possible,  but 
the  purpose  of  the  experiment  is  to  stress  the  system.  Experiment  3  determines  the 
probability  of  packet  intercept  under  the  addition  of  eight  different  network  loads. 
Table  3.6  summarizes  the  factor  levels  for  Experiments  1,  2,  and  3. 


Table  3.6:  Factor  Levels  for  Experiments  1,  2,  and  3,  for  the  TRacking  and  Analysis 
for  Peer-to-Peer  2  System. 


Factor 

Level  1 

Level  2 

Level  3 

Level  4 

Level  5 

Level  6 

Packet  Type 

Non 

BT/SIP/DNS 

BT  ON 

WORST 

BT  ON 

BEST 

BT  OFF 

SIP  INV  ON 

SMALL  BEST 

SIP  INV  ON 

LARGE  WORST 

Approximate 

Network  Load 

None 

20% 

30% 

40% 

50% 

60% 

Level  7 

Level  8 

Level  9 

Level  10 

Level  11 

Level  12 

SIP  INV 

OFF  LARGE 

SIP  BYE  ON 

SMALL  BEST 

SIP  BYE  ON 

LARGE  WORST 

DNS  OFF 

SMALL 

DNS  OFF 

LARGE 

DNS  ON 

LARGE  WORST 

70% 

80% 

93% 

Experiment  4  tests  how  increasing  the  hash  list  size  affects  the  packet  processing 
time.  The  line  speed  of  1000  Mbps  remains  the  same  and  the  TRAPP-2  software 
is  unchanged.  Only  large  DNS  packets  not  on  the  whitelist  are  used  (DNS-OFF- 
LARGE).  This  ensures  that  the  binary  search  algorithm  is  exhausted  and  that  the 
packet  is  logged  as  suspicious.  Table  3.7  summarizes  the  factor  levels  for  Experiment 
4. 
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Table  3.7:  Factor  Levels  for  Experiment  4  for  the  TRacking  and  Analysis  for  Peer- 
to-Peer  2  System. 


Factor 

Level  1 

Level  2 

Level  3 

Level  4 

Level  5 

Level  6 

DNS  Hash  List  Size 

2,000 

4,000 

8,000 

16,000 

32,000 

64,000 

Level  7 

Level  8 

Level  9 

Level  10 

Level  11 

Level  12 

128,000 

256,000 

512,000 

1,024,000 

2,048,000 

4,096,000 

Level  13 

Level  14 

Level  15 

Level  16 

Level  17 

8,192,000 

16,384,000 

32,768,000 

65,536,000 

131,072,000 

3. 9  Evaluation  Technique 

Direct  measurement  is  selected  as  the  evaluation  technique  for  the  experiments 
because  the  TRAPP-2  system  is  a  real  and  physical  system.  The  experimental  hard¬ 
ware  conhguration  setup  is  on  the  right  side  of  Figure  3.7.  The  same  network  is  used 
to  create  the  packets  of  interest.  The  packet  creation  conhguration  is  on  the  left  side 
of  Figure  3.7.  The  packet  creation  laptops  are  disconnected  from  the  network  prior 
to  conducting  the  experiments. 

The  experimental  conhguration  consists  of  the  following  hardware: 

•  1  Cisco  gigabit  24-port  switch  (model  WS-C3560G-24PS-S).  The  switch  is  con- 
hgured  with  22  standard  ports  and  2  SPAN  ports. 

•  1  Xilinx  Virtex-5  FPGA  (model  FXT  ML510),  the  SUT,  connected  to  one  of 
the  switch’s  SPAN  ports. 

•  1  Dell  Latitude  D630  laptop  loaded  with  the  Windows’s  XP  Service  Pack  3 
Operating  System.  It  contains  Wireshark  1.0.5  [Wir09],  connected  to  the  other 
switch’s  SPAN  port,  acting  as  the  control  packet  sniher.  This  laptop  is  also 
used  to  program  the  FPGA  via  Universal  Serial  Bus  and  provide  Standard 
Input/Output  for  the  FPGA  through  a  RS232  interface. 


•  1  Dell  Latitude  D630  laptop  loaded  with  Backtrack  4  [REIO]  and  the  tcpreplay 
utility,  version  3.4.3  [TcplO],  to  inject  packets  into  the  network. 

•  1  Dell  Latitude  D630  loaded  with  the  Ubuntu  Desktop  9.10  Operating  Sys¬ 
tem.  This  laptop  contains  the  Linux  pktgen  utility  to  create  different  network 
utilizations  on  the  network. 


Figure  3.7:  Packet  Creation  and  Experimental  Hardware  Configuration  Setup  for 
the  TRacking  and  Analysis  for  Peer-to-Peer  2  System. 


The  packet  creation  configuration  consists  of  the  following  hardware: 

•  2  Dell  Latitude  D630  laptops  loaded  with  the  Window’s  XP  Service  Pack  3  Op¬ 
erating  System.  They  both  contain  uTorrent  2.0  [uTolO]  and  X-Lite  3.0  [CoulO], 
BitTorrent  and  VoIP  clients,  respectively. 

•  1  Dell  Latitude  D630  laptop  loaded  with  trixbox  2. 8. 0.3  [TrilO],  based  on  Cen- 
tOS  release  5.4,  acting  as  the  SIP  proxy  and  registrar  server  for  the  X-Lite  VoIP 
clients. 

•  1  Dell  Inspiron  640m  laptop  loaded  with  Ubuntu  Server  9.10  used  as  a  DNS 
server.  The  DNS  server  is  required  to  create  SIP  packets  that  contain  large 
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domain  names.  This  server  is  not  used  for  any  of  the  malicious  DNS  packet 
creation.  The  malicious  DNS  packets  are  created  using  Iodine  [Kry09]. 

The  actual  experimental  setup  is  shown  in  Figure  3.8. 


Figure  3.8:  Experimental  Setup  for  the  TRacking  and  Analysis  for  Peer-to-Peer  2 
System. 

3.9.1  Calculating  Packet  Processing  Time.  For  Experiment  1  and  Experi¬ 
ment  4,  a  series  of  50  packets  is  sent  from  the  Backtrack  laptop  using  the  tcpreplay 
utility.  Using  50  packets  allows  for  sufficiently  small  confidence  intervals  to  compare 
the  results.  For  each  of  the  three  replications,  a  series  of  50  packets  is  sent  and  the 
number  of  CPU  cycles  required  to  process  the  packet  is  recorded.  Prior  to  sending 
the  50  packets,  five  packets  are  sent  to  the  system  to  “warm  up”  the  board  by  caching 
the  data  and  instructions  used  by  the  processor.  No  additional  network  utilization  is 
injected  into  the  system. 

3.9.2  Calculating  Probability  of  Packet  Intercept.  For  Experiment  2,  a  series 
of  400  packets  is  sent  as  fast  as  possible  from  the  Backtrack  laptop  using  the  tcpreplay 
utility.  For  each  of  the  three  replications,  a  series  of  400  protocol-under-test  packets  is 
flooded  into  the  TRAPP-2  system  and  the  number  of  packets  intercepted  is  recorded. 
To  stress  the  system  and  provide  a  sufficiently  small  confidence  interval,  400  packets 
is  selected.  Prior  to  sending  the  400  packets,  five  packets  are  sent  to  the  system  to 
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“warm  up”  the  board  by  caching  the  data  and  instructions  used  by  the  processor. 
No  additional  network  load  is  injected  into  the  system.  The  network  utilization  is 
measured  using  Wireshark. 

For  Experiment  3,  a  series  of  300  packets,  sent  at  200  ms  intervals,  is  sent  from 
the  Backtrack  laptop  using  the  tcpreplay  utility.  Injecting  the  packets  at  200  ms 
intervals  allows  for  the  result  of  each  trial  (captured  or  not  captured)  to  be  inde¬ 
pendent.  The  sample  size  of  300  packets  produces  a  good  binomial  distribution  with 
small  conhdence  intervals.  For  each  of  the  three  replications,  a  series  of  300  packets 
is  sent  into  the  TRAPP-2  system  and  the  number  of  packets  captured  is  recorded. 
Prior  to  sending  the  300  packets,  five  packets  are  sent  to  the  system  to  “warm  up”  the 
board  by  caching  the  data  and  instructions  used  by  the  processor.  Additionally,  prior 
to  injecting  the  300  packets,  the  Linux  pktgen  utility  is  activated  to  add  the  various 
network  loads  to  the  system.  The  network  utilization  is  measured  using  variables 
within  the  Linux  pktgen  utility.  For  Experiment  2  and  Experiment  3,  Wireshark  is 
used  as  the  probability  of  packet  intercept  control. 

3.10  Experimental  Design 

3.10.1  Experiment  1.  Experiment  1  is  a  partial  factorial  design  and  calcu¬ 
lates  the  packet  processing  time  for  12  packet  types  and  consists  of  1800  trials  (12 
packet  types  x  50  packets  x  3  replications).  For  packet  processing  time,  a  one- variable 
t-test  is  used  to  determine  the  mean  packet  processing  time  in  CPU  cycles,  the  stan¬ 
dard  deviation,  the  standard  error  of  the  mean,  and  a  95%  conhdence  interval  for  the 
mean. 


3.10.2  Experiment  2.  Experiment  2  is  a  partial  factorial  design  and  calcu¬ 
lates  the  probability  of  packet  intercept  for  the  four  worst-case  scenario  packets:  ET¬ 
ON- WORST,  SIP-INVITE-ON-LARGE- WORST,  SIP-BYE-ON-LARGE- WORST,  and 
DNS-OFF-LARGE.  Depending  on  the  type  of  packet  being  investigated,  the  network 
utilization  consists  of  either  all-Bit Torrent,  all-SIP,  or  all-DNS  packets  that  are  on  the 
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list.  The  test  consists  of  4800  trials  (4  packet  types  x  400  packets  x  3  replications). 
For  the  probability  of  packet  intercept,  a  one-proportion  conhdence  interval  analysis 
is  performed  on  the  binomial  variable  to  determine  the  probability  of  packet  intercept 
and  a  95%  conhdence  interval  for  the  proportion. 

3.10.3  Experiment  3.  Experiment  3  is  a  partial  factorial  design  and  cal¬ 
culates  the  probability  of  packet  intercept  for  the  same  four  worst-case  scenario 
packet  types:  BT-ON-WORST,  SIP-INVITE-ON-LARGE- WORST,  SIP-BYE-ON- 
LARGE-WORST,  and  DNS-OFF-LARGE.  However,  the  packets  are  injected  into 
the  system  at  200  ms  intervals.  Experiment  3  is  performed  under  eight  different  non- 
Bit Torrent /SIP/DNS  network  utilizations,  generated  using  the  Linux  pktgen  utility, 
and  consists  of  28,800  trials  (4  packet  types  x  300  packets  x  8  utilizations  x  3  repli¬ 
cations).  For  the  probability  of  packet  intercept,  a  one-proportion  conhdence  interval 
analysis  is  performed  on  the  binomial  variable  to  determine  the  probability  of  packet 
intercept  and  a  95%  conhdence  interval  for  the  proportion. 

3.10.4  Experiment  4-  Experiment  4  is  a  partial  factorial  design  and  calcu¬ 
lates  the  packet  processing  time  for  the  DNS-OFF-LARGE  packet.  This  packet  is 
used  because  it  is  the  worst-case  DNS  packet.  With  the  worst-case  DNS  packet,  the 
entire  hash  list  must  be  searched.  Experiment  4  consists  of  2,550  trials  (17  list  sizes 
X  1  packet  type  x  50  packets  x  3  replications).  For  packet  processing  time,  a  one- 
variable  t-test  is  used  to  determine  the  mean  packet  processing  time  in  GPU  cycles, 
the  standard  deviation,  the  standard  error  of  the  mean,  and  a  95%  conhdence  interval 
for  the  mean. 

3.11  Methodology  Summary 

This  section  explains  the  experimental  methods  used  to  evaluate  the  perfor¬ 
mance  of  the  TRAPP-2  system  under  diherent  workloads  and  network  utilizations. 
The  performance  is  measured  by  calculating  the  packet  processing  time  and  the  prob¬ 
ability  of  packet  intercept.  Four  partial  factorial  experiments  are  conducted  with  the 
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TRAPP-2  system.  Experiment  1  determines  the  packet  processing  times  for  pack¬ 
ets  of  interest.  Experiment  2  determines  the  probability  of  packet  intercept  under  a 
flood  of  400  packets  of  interest.  Experiment  3  determines  the  probability  of  packet 
intercept  under  various  network  utilizations  generated  using  the  Linux  pktgen  utility. 
Lastly,  Experiment  4  determines  how  increasing  the  hash  list  size  affects  the  packet 
processing  time. 
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IV.  Results  and  Analysis 


This  chapter  presents  the  results  and  analysis  of  the  four  experiments.  Section  4.1 
details  the  results  and  analysis  from  Experiment  1.  Section  4.2  details  the 
results  and  analysis  from  Experiment  2.  Section  4.3  details  the  results  and  analysis 
from  Experiment  3.  Section  4.4  presents  the  results  and  analysis  from  Experiment 
4.  An  overall  analysis  is  provided  in  Section  4.5,  and  the  chapter  is  summarized  in 
Section  4.6. 


4-1  Results  and  Analysis  of  Experiment  1 

Table  4.1  summarizes  the  results  of  a  one- variable  t-test  using  12  different  packet 
types.  The  table  contains  the  number  of  packets  sent,  mean  number  of  CPU  cycles 
required  to  process  the  packet,  the  standard  deviation,  the  standard  error  of  the  mean, 
and  the  95%  confidence  interval  for  the  mean.  The  data  is  sorted  based  on  the  mean 
CPU  cycles  (packet  processing  time). 


Table  4.1:  Sorted  Mean  Packet  Processing  Times  for  Experiment  1. 


Packet 

Type 

Packets 

Sent 

Mean 

GPU 

Gycles 

Stand. 

Dev. 

Standard 

Error  of 

the  Mean 

Gonfidence 

Interval 

(95%) 

DNS  OFF  SMALL 

150 

1671.83 

53.33 

4.35 

(1663.22,  1680.43) 

BT  OFF 

150 

1973.00 

0.00 

0.00 

(1973.00,  1973.00) 

BT  ON  BEST 

150 

2085.72 

52.03 

4.25 

(2077.33,  2094.11) 

BT  ON  WORST 

150 

2217.39 

50.83 

4.15 

(2209.19,  2225.59) 

Non  BT/SIP/DNS 

150 

4985.00 

0.00 

0.00 

(4985.00,  4985.00) 

DNS  ON  LARGE  WORST 

150 

5172.00 

0.00 

0.00 

(5172.00,  5172.00) 

DNS  OFF  LARGE 

150 

5539.47 

57.02 

4.66 

(5530.27,  5548.67) 

SIP  BYE  ON  SMALL  BEST 

150 

8580.32 

55.68 

4.55 

(8571.34,  8589.30) 

SIP  INV  ON  SMALL  BEST 

150 

15283.0 

545.8 

44.6 

(15195.0,  15371.1) 

SIP  BYE  ON  LARGE  WORST 

150 

26071.6 

655.6 

53.5 

(25965.9,  26177.4) 

SIP  INV  OFF  LARGE 

150 

31092.0 

0.0 

0.0 

(31092.0,  31092.0) 

SIP  INV  ON  LARGE  WORST 

150 

34226.6 

879.8 

71.8 

(34084.6,  34368.5) 

Figure  4.1  plots  the  sorted  mean  packet  processing  times  for  each  of  the  12 
different  packet  types  from  Table  4.1.  The  range  of  mean  packet  processing  time  is 
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1,671.83  to  34,226.6  CPU  cycles.  DNS  and  Bit  Torrent  packets  tend  to  be  on  the  lower 
end,  while  all  SIP  packets  are  on  the  higher  end  of  the  range. 
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Fignre  4.1:  Mean  Packet  Processing  Times  for  the  12  Different  Packet  Types  for 
Experiment  1. 


4-.  1.1  BitTorrent  Packet  Processing  Time.  Table  4.2  highlights  the  Bit  Tor¬ 
rent  packet  processing  time  valnes  from  Experiment  1.  Fignre  4.2  plots  the  sorted 
mean  CPU  cycles  (packet  processing  time)  and  the  95%  conhdence  intervals  for  the 
BitTorrent  packets.  By  nsing  the  worst-  and  best-case  scenario  BitTorrent  packets,  a 
range  of  2085.72  -  2,217.39  is  established  for  all  BitTorrent  packets  of  interest. 


Table  4.2:  Sorted  BitTorrent  Mean  Packet  Processing  Times  for  Experiment  1. 


Packet 

Type 

Packets 

Sent 

Mean 

CPU 

Cycles 

Stand. 

Dev. 

Standard 

Error  of 

the  Mean 

Confidence 

Interval 

(95%) 

BT  OFF 

150 

1973.00 

0.00 

0.00 

(1973.00,  1973.00) 

BT  ON  BEST 

150 

2085.72 

52.03 

4.25 

(2077.33,  2094.11) 

BT  ON  WORST 

150 

2217.39 

50.83 

4.15 

(2209.19,  2225.59) 
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Figure  4.2:  Mean  Packet  Processing  Times  for  Bit  Torrent  Packet  Types  for  Exper¬ 
iment  1. 

4-1.2  SIP  Packet  Processing  Time.  Table  4.3  highlights  the  SIP  packet 
processing  time  values  from  Experiment  1.  Figure  4.3  plots  the  sorted  mean  CPU 
cycles  (packet  processing  time)  and  95%  confidence  intervals  for  the  SIP  packets.  By 
using  the  worst-  and  best-case  scenario  for  SIP  INVITE  packets,  a  range  of  15,283.0  - 
34,226.6  is  established  for  all  SIP  INVITE  packets  of  interest.  By  using  the  worst-  and 
best-case  scenario  for  SIP  BYE  packets,  a  range  of  8,580.32  -  26,071.6  is  established 
for  all  SIP  BYE  packets  of  interest. 


Table  4.3:  Sorted  Session  Initiation  Protocol  Mean  Packet  Processing  Times  for 


Experiment  1. 


Packet 

Type 

Packets 

Sent 

Mean 

GPU 

Cycles 

Stand. 

Dev. 

Standard 

Error  of 

the  Mean 

Confidence 

Interval 

(95%) 

SIP  BYE  ON  SMALL  BEST 

150 

8580.32 

55.68 

4.55 

(8571.34,  8589.30) 

SIP  INV  ON  SMALL  BEST 

150 

15283.0 

545.8 

44.6 

(15195.0,  15371.1) 

SIP  BYE  ON  LARGE  WORST 

150 

26071.6 

655.6 

53.5 

(25965.9,  26177.4) 

SIP  INV  OFF  LARGE 

150 

31092.0 

0.0 

0.0 

(31092.0,  31092.0) 

SIP  INV  ON  LARGE  WORST 

150 

34226.6 

879.8 

71.8 

(34084.6,  34368.5) 
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Mean  Packet  Processing  Time  of  SIP  Packets 
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Figure  4.3:  Mean  Packet  Processing  Times  for  Session  Initiation  Protocol  Packet 

Types  for  Experiment  1. 


4-1.3  DNS  Packet  Processing  Time.  Table  4.4  highlights  the  DNS  packet 
processing  time  values  from  Experiment  1.  Figure  4.4  plots  the  sorted  mean  CPU 
cycles  (packet  processing  time)  and  95%  conhdence  intervals  for  the  DNS  packets. 
By  using  the  worst-  and  best-case  scenario  for  DNS  packets,  a  range  of  1,671.83  - 
5,539.47  is  established  for  all  DNS  packets  of  interest. 


Table  4.4:  Sorted  Domain  Name  System  Mean  Packet  Processing  Times  for  Exper- 
iment  1. _ 


Packet 

Type 

Packets 

Sent 

Mean 

CPU 

Cycles 

Stand. 

Dev. 

Standard 

Error  of 

the  Mean 

Confidence 

Interval 

(95%) 

DNS  OFF  SMALL 

150 

1671.83 

53.33 

4.35 

(1663.22,  1680.43) 

DNS  ON  LARGE  WORST 

150 

5172.00 

0.00 

0.00 

(5172.00,  5172.00) 

DNS  OFF  LARGE 

150 

5539.47 

57.02 

4.66 

(5530.27,  5548.67) 
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Figure  4.4:  Mean  Packet  Processing  Times  for  Domain  Name  System  Packet  Types 
for  Experiment  1. 

4- 1-4  Experiment  1  Analysis.  Bit  Torrent  and  DNS  packets  require  the 
least  amount  of  packet  processing  time.  This  is  due  to  the  small  byte  size  of  the 
packets.  The  packet  size  transfer  pilot  test,  mentioned  in  Section  3. 5. 1.3,  reveals  that 
transferring  the  packet  from  the  Ethernet  buffer  to  a  software  buffer  takes  significantly 
longer  for  larger  packets. 

All  Eve  types  of  SIP  packets  require  the  most  packet  processing  time.  This 
is  due  to  the  larger  byte  size  and  processing  required  of  SIP  packets  compared  to 
Bit  Torrent  and  DNS.  First,  the  TRAPP-2  system  must  copy  the  entire  packet  into  a 
software  buffer,  so  the  larger  SIP  packets  take  longer  to  transfer.  Secondly,  the  SIP 
packet  payload  must  be  searched  for  the  To:  and  From:  SIP  URIs  because  they  are 
not  at  a  fixed  location  in  the  payload.  Furthermore,  once  the  To:  and  From:  SIP 
URIs  are  extracted,  they  both  must  be  separately  sdbm  hashed  and  searched  against 
the  hash  list. 
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SIP  BYE  packets  have  a  smaller  packet  processing  time  than  SIP  INVITE  pack¬ 
ets  when  the  other  packet  characteristics  (on/off  hash  list,  and  hash  location)  are 
equal.  The  disparity  results  because  of  the  intrinsic  larger  packet  size  (approximately 
375  bytes)  of  SIP  INVITE  packets  over  SIP  BYE  packets. 


4.-2  Results  and  Analysis  of  Experiment  2 

Table  4.5  summarizes  the  results  of  flooding  the  TRAPP-2  system  with  400 
single  protocol-of-interest  packets.  The  protocol  of  interest  is  the  worst-case  scenario 
packet  for  Bit  Torrent,  SIP,  and  DNS.  However,  SIP  INVITE  and  SIP  BYE  packets  are 
tested  separately  even  though  they  fall  under  the  same  protocol.  As  a  comparison, 
the  number  of  packets  captured  by  Wireshark  is  also  presented  for  each  workload. 
The  table  also  contains  the  measured  network  utilization,  the  probability  of  packet 
intercept,  and  the  95%  conhdence  interval  for  the  probability  of  packet  intercept.  The 
data  is  sorted  based  on  the  network  utilization  measured  using  Wireshark. 


Table  4.5:  Probability  of  Packet  Intercept  for  Flood  of  1200  (400  packets  x  3  repli¬ 


cations)  Worst-Case  Scenario  Packets  for  Experiment  2. 


Workload 

Network 

Utilization% 

Packets 

Captured 

(Events) 

Packets 

Sent 

(Trials) 

Prob.  of 

Packet 

Intercept 

Confidence 

Interval 

(95%) 

BT  (TRAPP-2) 

15.46 

1200 

1200 

1.0000 

(0.9975,  1.0000) 

BT  (Wireshark) 

15.46 

1200 

1200 

1.0000 

(0.9975,  1.0000) 

DNS  (TRAPP-2) 

23.82 

1039 

1200 

0.8658 

(0.8452,  0.8846) 

DNS  (Wireshark) 

23.82 

1200 

1200 

1.0000 

(0.9975,  1.0000) 

SIP  BYE  (TRAPP-2) 

94.75 

264 

1200 

0.2200 

(0.1969,  0.2445) 

SIP  BYE  (Wireshark) 

94.75 

1200 

1200 

1.0000 

(0.9975,  1.0000) 

SIP  INV  (TRAPP-2) 

99.48 

239 

1200 

0.1992 

(0.1769,  0.2229) 

SIP  INV  (Wireshark) 

99.48 

1200 

1200 

1.0000 

(0.9975,  1.0000) 

Figure  4.5  plots  the  results  from  Table  4.5.  For  BitTorrent  packets,  both  the 
TRAPP-2  system  and  Wireshark  intercept  100%  of  the  1200  packets  (400  packets  x 
3  replications).  However,  the  network  utilization  measured  during  the  test  is  only 
15.46%.  This  is  due  to  BitTorrent  relying  on  TCP,  which  uses  reliable  data  transfer 
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and  exponential  backoff  mechanisms  to  throttle  the  throughput.  For  DNS  packets, 
the  TRAPP-2  system  captures  86.58%  of  the  1200  packets,  while  Wireshark  captures 
100%.  The  network  utilization  measured  during  the  test  is  23.82%.  Although  DNS 
relies  on  UDP,  allowing  packets  to  be  sent  faster  than  TCP,  the  smaller  size  of  the 
packets  results  in  a  smaller  network  utilization.  For  SIP  BYE  packets,  the  TRAPP-2 
system  captures  22.00%  of  the  1200  packets  while  Wireshark  captures  100%  of  the 
packets.  The  network  utilization  measured  during  the  test  is  94.75%.  The  larger  SIP 
BYE  packet  byte  size  and  reliance  on  UDP  results  in  an  increased  network  utilization. 
For  the  hnal  packet,  SIP  INVITE,  the  TRAPP-2  system  captures  19.92%  of  the  1200 
packets,  while  Wireshark  again  captures  100%  of  the  packets.  The  1500-byte  SIP 
packet  transferred  over  UDP  results  in  the  highest  network  utilization  of  99.48%. 


Figure  4.5:  Network  Utilization  and  Probability  of  Packet  Intercept  vs  Flood  of  1200 
packets  (400  packets  x  3  replications)  Worst-Case  Scenario  Packets  for  Experiment  2. 

4-2.1  Experiment  2  Analysis.  Wireshark  outperforms  the  TRAPP-2  system 
in  capturing  a  flood  of  400  packets  for  DNS,  SIP  BYE,  and  SIP  INVITE  packet 
types.  This  is  due  to  the  fact  that  Wireshark  does  not  perform  any  processing  on 
the  packets.  As  for  the  TRAPP-2  system,  it  must  process  400  of  the  worst-case 
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scenario  packets  back-to-back.  The  results  are  expected  since  DNS,  SIP  BYE,  and 
SIP  INVITE  packets  require  more  CPU  cycles  to  process  than  Bit  Torrent  packets  as 
revealed  in  Experiment  1.  Both  the  TRAPP-2  system  and  Wireshark  capture  100% 
of  Bit  Torrent  packets,  however,  the  network  utilization  is  only  15.46%.  Although 
Wireshark  outperforms  the  TRAPP-2  system  for  three  of  the  four  packets,  this  type 
of  traffic  is  unrealistic  in  a  real  world  network.  For  all  four  of  these  types  of  packets, 
the  same  packet  would  not  typically  be  sent  back-to-back  as  fast  as  possible. 


4.3  Results  and  Analysis  of  Experiment  3 

4-3.1  BitTorrent  Probability  of  Packet  Intercept.  Table  4.6  presents  the 
results  for  the  BitTorrent  packet  under  eight  different  network  utilizations.  As  a 
reminder,  the  network  utilizations  are  generated  by  adding  a  load  using  the  Linux 
pktgen  utility.  The  packet  selected  for  the  test  is  BT-ON-WORST,  the  worst-case 
scenario  BitTorrent  packet.  As  a  result  of  selecting  the  BT-ON-WORST  packet,  the 
data  in  Table  4.6  is  assumed  to  be  the  worst-case  scenario  for  a  BitTorrent  packet 
with  a  hash  on  a  hash  list  size  of  1000.  The  probability  of  packet  intercept  is  the 
percentage  of  900  packets  (300  packets  x  3  replications)  captured. 


Table  4.6:  Probability  of  Packet  Intercept  for  BitTorrent  Packets  Under  Various 
Network  Utilizations  for  Experiment  3. 


Utilization  % 

Prob.  of  Packet 

Intercept 

(TRAPP-2) 

Confidence 

Interval 

(95%) 

Prob.  of  Packet 

Intercept 

(Wireshark) 

Confidence 

Interval 

(95%) 

20.4% 

1.0000 

(0.9967,  1.0000) 

0.9589 

(0.9437,  0.9708) 

30.1% 

0.9733 

(0.9605,  0.9828) 

0.7167 

(0.6859,  0.7459) 

40.8% 

0.9667 

(0.9527,  0.9773) 

0.4122 

(0.3798,  0.4451) 

49.8% 

0.9711 

(0.9579,  0.9810) 

0.3733 

(0.3416,  0.4058) 

60.2% 

0.9578 

(0.9425,  0.9699) 

0.2556 

(0.2273,  0.2853) 

71.4% 

0.9456 

(0.9286,  0.9594) 

0.2356 

(0.2081,  0.2646) 

81.8% 

0.9578 

(0.9425,  0.9699) 

0.2089 

(0.1827,  0.2369) 

93.7% 

0.9556 

(0.9399,  0.9680) 

0.1722 

(0.1481,  0.1985) 
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Figure  4.6  shows  a  plot  of  the  probability  of  packet  intercept  for  both  the 
TRAPP-2  system  and  Wireshark  as  the  network  utilization  is  increased.  The  TRAPP- 
2  system  has  a  higher  probability  of  packet  intercept  for  every  network  utilization 
level.  For  the  20.4%  network  utilization,  TRAPP-2  captures  100%  of  BitTorrent 
packets  and  Wireshark  captures  95.89%.  Figure  4.6  reveals  the  approximate  and 
slight  linear  decrease  in  probability  of  packet  intercept  for  the  TRAPP-2  system,  as 
opposed  to  the  exponential  decrease  by  Wireshark,  when  the  network  utilization  is 
increased.  This  is  further  emphasized  by  the  fact  that  the  TRAPP-2  system  man¬ 
ages  to  capture  95.56%  of  BitTorrent  packets  at  the  maximum  network  utilization 
of  93.7%.  In  contrast,  Wireshark  only  captures  17.22%  of  BitTorrent  packets  at  the 
maximum  network  utilization. 


Figure  4.6:  Probability  of  Packet  Intercept  for  BitTorrent  Packets  vs  Various  Net¬ 
work  Utilizations  for  Experiment  3. 

4-3.2  SIP  INVITE  Probability  of  Packet  Intercept.  Table  4.7  presents  the 
results  for  the  SIP  INVITE  packet  under  eight  different  network  utilizations.  The 
packet  selected  for  the  test  is  SIP-INVITE-ON-LARGE-WORST,  the  worst-case  sce¬ 
nario  SIP  INVITE  packet.  As  a  result  of  selecting  the  SIP-INVITE-ON-LARGE- 
WORST  packet,  the  data  in  Table  4.7  is  assumed  to  be  the  worst-case  scenario  for  a 
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SIP  INVITE  packet  with  a  hash  on  a  hash  list  size  of  1000.  The  probability  of  packet 
intercept  is  the  percentage  of  900  packets  (300  packets  x  3  replications)  captured. 


Table  4.7:  Probability  of  Packet  Intercept  for  Session  Initiation  Protocol  INVITE 
Packets  Under  Various  Network  Utilizations  for  Experiment  3. 


Utilization  % 

Prob.  of  Packet 

Intercept 

(TRAPP-2) 

Confidence 

Interval 

(95%) 

Prob.  of  Packet 

Intercept 

(Wireshark) 

Confidence 

Interval 

(95%) 

20.4% 

1.0000 

(0.9967,  I.OOOO) 

0.9600 

(0.9450,  0.9718) 

30.1% 

0.4256 

(0.3929,  0.4586) 

0.6867 

(0.6552,  0.7168) 

40.8% 

0.3144 

(0.2842,  0.3459) 

0.4467 

(0.4138,  0.4798) 

49.8% 

0.2733 

(0.2444,  0.3037) 

0.3478 

(0.3166,  0.3799) 

60.2% 

0.2778 

(0.2487,  0.3082) 

0.2589 

(0.2305,  0.2888) 

71.4% 

0.2522 

(0.2241,  0.2819) 

0.2256 

(0.1986,  0.2542) 

81.8% 

0.2322 

(0.2049,  0.2612) 

0.2200 

(0.1933,  0.2485) 

93.7% 

0.2078 

(0.1817,  0.2357) 

0.1633 

(0.1397,  0.1891) 

Figure  4.7  shows  a  plot  of  the  probability  of  packet  intercept  for  both  the 
TRAPP-2  system  and  Wireshark  as  the  network  utilization  is  increased.  For  the  20.4% 
network  utilization,  TRAPP-2  captures  100%  of  SIP  INVITE  packets  and  Wireshark 
captures  96.00%.  The  TRAPP-2  system  has  a  higher  probability  of  packet  intercept 
for  the  20.4%  network  utilization,  drops  below  Wireshark  in  the  30.1%  -  49.8%  range, 
then  exceeds  Wireshark  for  the  remaining  network  utilizations.  Figure  4.7  reveals 
the  approximate  exponential  decrease  in  probability  of  packet  intercept  for  both  the 
TRAPP-2  system  and  Wireshark  when  the  network  utilization  is  increased. 
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Figure  4.7:  Probability  of  Packet  Intercept  for  Session  Initiation  Protocol  INVITE 
Packets  vs  Various  Network  Utilizations  for  Experiment  3. 

4-3.3  SIP  BYE  Probability  of  Packet  Intercept.  Table  4.8  presents  the 
results  for  the  SIP  BYE  packet  under  eight  different  network  utilizations.  The  packet 
selected  for  the  test  is  SIP-BYE-ON-LARGE-WORST,  the  worst-case  scenario  SIP 
BYE  packet.  As  a  result  of  selecting  the  SIP-BYE-ON-LARGE- WORST  packet,  the 
data  in  Table  4.8  is  assumed  to  be  the  worst-case  scenario  for  a  SIP  BYE  packet 
with  a  hash  on  a  hash  list  size  of  1000.  The  probability  of  packet  intercept  is  the 
percentage  of  900  packets  (300  packets  x  3  replications)  captured. 


Table  4.8:  Probability  of  Packet  Intercept  for  Session  Initiation  Protocol  BYE 

Packets  Under  Various  Network  Utilizations  for  Experiment  3. 


Utilization  % 

Prob.  of  Packet 

Intercept 

(TRAPP-2) 

Confidence 

Interval 

(95%) 

Prob.  of  Packet 

Intercept 

(Wireshark) 

Confidence 

Interval 

(95%) 

20.4% 

1.0000 

(0.9967,  1.0000) 

0.9633 

(0.9488,  0.9746) 

30.1% 

0.6344 

(0.6020,  0.6659) 

0.6778 

(0.6461,  0.7082) 

40.8% 

0.5189 

(0.4856,  0.5519) 

0.4200 

(0.3875,  0.4530) 

49.8% 

0.4600 

(0.4270,  0.4932) 

0.3078 

(0.2777,  0.3390) 

60.2% 

0.5167 

(0.4834,  0.5497) 

0.3111 

(0.2809,  0.3424) 

71.4% 

0.4711 

(0.4380,  0.5043) 

0.2556 

(0.2273,  0.2853) 

81.8% 

0.4544 

(0.4215,  0.4876) 

0.1989 

(0.1732,  0.2264) 

93.7% 

0.3711 

(0.3394,  0.4036) 

0.1589 

(0.1355,  0.1844) 
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Figure  4.8  shows  a  plot  of  the  probability  of  packet  intercept  for  both  the 
TRAPP-2  system  and  Wireshark  as  the  network  utilization  is  increased.  For  the 
20.4%  network  utilization,  TRAPP-2  captures  100%  of  SIP  BYE  packets  and  Wire- 
shark  captures  96.33%.  The  TRAPP-2  system  has  a  higher  probability  of  packet  inter¬ 
cept  for  the  20.4%  network  utilization,  drops  below  Wireshark  at  30.1%,  then  exceeds 
Wireshark  for  the  remaining  network  utilizations.  Figure  4.8  reveals  the  approximate 
exponential  decrease  in  probability  of  packet  intercept  for  both  the  TRAPP-2  system 
and  Wireshark  when  the  network  utilization  is  increased.  For  both  the  TRAPP-2 
system  and  Wireshark,  a  small  bump  in  the  probability  of  packet  intercept  is  visible 
at  the  60.2%  network  utilization.  The  reason  for  the  bump  appearing  in  both  the 
TRAPP-2  system  and  Wireshark  results  is  unknown. 


Figure  4.8:  Probability  of  Packet  Intercept  for  Session  Initiation  Protocol  BYE 

Packets  vs  Various  Network  Utilizations  for  Experiment  3. 

J1..3.4  DNS  Probability  of  Packet  Intercept.  Table  4.9  presents  the  results 
for  the  DNS  packet  under  eight  different  network  utilizations.  The  packet  selected 
for  the  test  is  DNS-OFF-LARGE,  the  worst-case  scenario  DNS  packet.  As  a  result 
of  selecting  the  DNS-OFF-LARGE  packet,  the  data  in  Table  4.9  is  assumed  to  be 
the  worst-case  scenario  for  a  DNS  packet  with  a  hash  off  a  hash  list  size  of  1000. 


75 


The  probability  of  packet  intercept  is  the  percentage  of  900  packets  (300  packets  x  3 
replications)  captured. 


Table  4.9:  Probability  of  Packet  Intercept  for  Domain  Name  System  Packets  Under 
Various  Network  Utilizations  for  Experiment  3. 


Utilization  % 

Prob.  of  Packet 

Intercept 

(TRAPP-2) 

Confidence 

Interval 

(95%) 

Prob.  of  Packet 

Intercept 

(Wireshark) 

Confidence 

Interval 

(95%) 

20.4% 

1.0000 

(0.9967,  I.OOOO) 

0.9567 

(0.9412,  0.9690) 

30.1% 

0.9789 

(0.9672,  0.9872) 

0.6544 

(0.6223,  0.6855) 

40.8% 

0.9644 

(0.9501,  0.9755) 

0.4500 

(0.4171,  0.4831) 

49.8% 

0.9611 

(0.9463,  0.9727) 

0.3556 

(0.3242,  0.3878) 

60.2% 

0.9100 

(0.8893,  0.9278) 

0.3144 

(0.2842,  0.3459) 

71.4% 

0.9200 

(0.9003,  0.9368) 

0.2289 

(0.2018,  0.2577) 

81.8% 

0.8911 

(0.8689,  0.9107) 

0.2500 

(0.2220,  0.2796) 

93.7% 

0.9189 

(0.8990,  0.9358) 

0.1800 

(0.1554,  0.2066) 

Figure  4.9  shows  a  plot  of  the  probability  of  packet  intercept  for  both  the 
TRAPP-2  system  and  Wireshark  as  the  network  utilization  is  increased.  The  TRAPP- 
2  system  has  a  higher  probability  of  packet  intercept  for  every  network  utilization  level. 
For  the  20.4%  network  utilization,  TRAPP-2  captures  100%  of  SIP  BYE  packets  and 
Wireshark  captures  95.67%.  Figure  4.9  reveals  the  approximate  and  slight  linear  de¬ 
crease  in  probability  of  packet  intercept  for  the  TRAPP-2  system,  as  opposed  to  the 
exponential  decrease  by  Wireshark,  when  the  network  utilization  is  increased.  This  is 
further  emphasized  by  the  fact  that  the  TRAPP-2  system  manages  to  capture  91.89% 
of  DNS  packets  at  the  maximum  network  utilization  of  93.7%.  In  contrast,  Wireshark 
only  captures  18.00%  of  DNS  packets  at  the  maximum  network  utilization. 
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Figure  4.9:  Probability  of  Packet  Intercept  for  Domain  Name  System  Packets  vs 
Various  Network  Utilizations  for  Experiment  3. 

4-3.5  Experiment  3  Analysis.  The  TRAPP-2  system  significantly  outper¬ 
forms  Wireshark  in  capturing  Bit  Torrent  and  DNS  packets.  The  TRAPP-2  system 
captures  95.56%  of  BitTorrent  and  91.89%  of  DNS  packets  under  a  93.7%  network 
utilization.  Wireshark  captures  17.22%  of  BitTorrent  and  18.00%  of  DNS  packets 
under  the  same  93.7%  network  utilization.  As  a  reminder,  the  packets  selected  for 
this  test  are  the  worst-case  scenario  packets. 

The  TRAPP-2  system  and  Wireshark  return  similar  performances  for  SIP  IN¬ 
VITE  packets.  However,  the  TRAPP-2  system  captures  20.78%  of  packets  compared 
to  Wireshark’s  16.33%  under  a  93.7%  network  utilization.  The  TRAPP-2  system  and 
Wireshark  return  similar  performances  for  SIP  BYE  packets  at  the  20.4%  and  30.1% 
network  utilization.  After  that,  the  TRAPP-2  system  outperforms  Wireshark.  Un¬ 
der  a  93.7%  network  utilization,  the  TRAPP-2  system  captures  37.11%  of  SIP  BYE 
packets  compared  to  15.89%  by  Wireshark.  The  TRAPP-2  system  has  a  smaller  prob¬ 
ability  of  packet  intercept  for  SIP  INVITE  and  SIP  BYE  packets  due  to  the  larger 
packet  size  and  packet  processing  time. 

In  general,  the  probability  of  packet  intercept  for  Wireshark,  regardless  of  packet 
type,  follows  the  same  exponential  decrease  as  the  network  utilization  is  increased. 
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The  probability  of  packet  intercept  for  the  TRAPP-2  system  depends  on  the  type  of 
packet  being  captured.  For  the  TRAPP-2  system,  the  smaller  Bit  Torrent  and  DNS 
packets  outperform  the  larger  SIP  INVITE  and  SIP  BYE  packets  at  higher  network 
utilizations. 


4.4  Results  and  Analysis  of  Experiment  4 

Table  4.10  summarizes  the  results  of  a  one- variable  t-test  using  17  different  hash 
list  sizes.  The  packet  selected  for  this  test  is  the  DNS-OFF-LARGE,  the  worst-case 
scenario  DNS  packet.  The  packet  is  selected  because  the  entire  hash  list  search  is 
exhausted.  The  table  contains  the  number  of  packets  sent,  mean  number  of  CPU 
cycles  required  to  process  the  DNS  packet,  the  standard  deviation,  the  standard  error 
of  the  mean,  and  the  95%  conhdence  interval  for  the  mean. 

Table  4.10:  Mean  Packet  Processing  Times  for  17  Different  Hash  List  Sizes  for 

Experiment  4. 


Hash  List 

Items 

Packets 

Sent 

Mean 

CPU  Cycles 

Standard 

Deviation 

Standard  Error 

of  the  Mean 

Confidence 

Interval  (95%) 

2,000 

150 

5683.87 

66.14 

5.40 

(5673.19,  5694.54) 

4,000 

150 

5697.71 

60.08 

4.91 

(5688.01,  5707.40) 

8,000 

150 

5707.06 

56.62 

4.62 

(5697.93,  5716.19) 

16,000 

150 

5723.72 

55.12 

4.50 

(5714.83,  5732.61) 

32,000 

150 

5739.69 

52.16 

4.26 

(5731.27,  5748.10) 

64,000 

150 

5756.57 

60.68 

4.95 

(5746.78,  5766.36) 

128,000 

150 

5780.12 

55.10 

4.50 

(5771.23,  5789.01) 

256,000 

150 

5799.23 

60.81 

4.97 

(5789.42,  5809.04) 

512,000 

150 

5814.21 

66.36 

5.42 

(5803.50,  5824.91) 

1,024,000 

150 

5830.26 

77.46 

6.32 

(5817.76,  5842.76) 

2,048,000 

150 

5848.29 

70.11 

5.72 

(5836.98,  5859.61) 

4,096,000 

150 

5867.69 

73.64 

6.01 

(5855.81,  5879.57) 

8,192,000 

150 

5886.57 

80.20 

6.55 

(5873.63,  5899.51) 

16,384,000 

150 

5901.64 

81.78 

6.68 

(5888.45,  5914.83) 

32,768,000 

150 

5918.90 

84.62 

6.91 

(5905.25,  5932.55) 

65,536,000 

150 

5931.99 

52.17 

4.26 

(5923.58,  5940.41) 

131,072,000 

150 

5938.81 

39.85 

3.25 

(5932.38,  5945.24) 
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Figure  4.10  shows  a  plot  of  the  mean  packet  processing  time  as  the  hash  list 
size  is  increased.  The  smallest  hash  list  size  is  2,000  and  is  doubled  up  to  131,072,000 
unique  hash  items  on  the  hash  list.  The  doubling  of  the  hash  list  size  results  in 
a  logarithmic  plot  for  the  mean  packet  processing  times.  Note  that  the  difference 
between  mean  packet  processing  times  for  the  hash  list  size  of  2,000  and  131,072,000 
is  approximately  only  255  CPU  cycles. 


Scatterplot  of  Mean  Packet  Processing  Time  vs  Hash  List  Items 


Figure  4.10:  Mean  Packet  Processing  Times  vs  17  Different  Hash  List  Sizes  for 

Experiment  4. 

To  verify  the  logarithmic  nature  of  the  mean  packet  processing  times  as  the  hash 
list  size  is  doubled,  a  separate  plot  is  required.  Figure  4.11  plots  the  mean  packet 
processing  times  against  the  natural  log  of  the  hash  list  sizes.  The  linearity  of  the 
plot  asserts  the  logarithmic  nature  of  doubling  the  hash  list  size. 
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Scatterplot  of  Mean  Packet  Processing  Time  vs  Ln(Hash  List  Items) 


Figure  4.11:  Mean  Packet  Processing  Times  vs  Natural  Log  of  17  Different  Hash 
List  Sizes  for  Experiment  4. 

Table  4.11  displays  the  mean  packet  processing  times  and  the  difference  between 
them.  For  example,  the  hash  list  size  of  4,000  takes  an  average  of  13.84  more  CPU 
cycles  than  the  hash  list  size  of  2,000.  The  range  is  from  6.22  -  23.55  CPU  cycles  and 
the  overall  average  difference  between  the  means  is  15.93  CPU  cycles.  This  results 
in  the  average  addition  of  15.93  CPU  cycles  to  the  overall  packet  processing  time  for 
each  doubling  of  the  hash  list  size. 
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Table  4.11:  Difference  Between  Mean  Packet  Processing  Times  for  17  Different 

Hash  List  Sizes  for  Experiment  4. 


Hash  List 

Items 

Mean 

CPU  Cycles 

Difference 

Between  Means 

2,000 

5683.87 

- 

4,000 

5697.71 

13.84 

8,000 

5707.06 

9.35 

16,000 

5723.72 

16.66 

32,000 

5739.69 

15.97 

64,000 

5756.57 

16.88 

128,000 

5780.12 

23.55 

256,000 

5799.23 

19.11 

512,000 

5814.21 

14.98 

1,024,000 

5830.26 

16.05 

2,048,000 

5848.29 

18.03 

4,096,000 

5867.69 

19.40 

8,192,000 

5886.57 

18.88 

16,384,000 

5901.64 

15.07 

32,768,000 

5918.90 

17.26 

65,536,000 

5931.99 

13.09 

131,072,000 

5938.81 

6.82 

Average  Difference 

Between  Means 

15.93 

4-4-i  Experiment  4  Analysis.  Doubling  the  hash  list  size  results  in  an 
average  mean  increase  of  15.93  CPU  cycles  for  the  DNS  packet.  The  four-byte  sdbm 
hash  contains  eight  hexadecimal  values,  e.g.,  1F7B032A.  Thus,  there  are  a  total  of 
4,294,967,296  (16®)  unique  hashes  for  a  four-byte  hash.  The  maximum  hash  list 
size  of  131,072,000  unique  items  for  the  TRAPP-2  system  equates  to  3.05%  of  the 
total  number  of  hashes  due  to  the  512  MB  memory  limit.  If  a  system  of  4,294,967,296 
unique  hashes  is  desired,  then  16  GB  of  storage  is  required.  The  number  4,294,967,296 
can  be  achieved  by  doubling  the  max  list  size  of  131,072,000  approximately  hve  more 
times.  With  a  mean  of  approximately  16  additional  CPU  cycles  per  doubling  of  the 
hashlist,  4,294,967,296  unique  hash  items  can  be  searched  in  additional  5  x  16  = 
80  CPU  cycles.  This  assumes  the  hash  list  is  sorted  to  cater  to  the  binary  search 
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algorithm.  These  results  are  encouraging  for  future  research  that  will  rely  on  larger 
hash  list  sizes. 

4-5  Overall  Analysis 

The  results  from  Experiment  1  assist  in  understanding  the  results  of  Experi¬ 
ment  3.  The  smaller  packet  processing  times  for  Bit  Torrent  and  DNS  packets  allows 
the  TRAPP-2  system  to  capture  them  with  a  probability  of  packet  intercept  greater 
than  90%  under  the  maximum  network  utilization  of  93.7%.  Both  the  SIP  INVITE 
and  SIP  BYE  packets  take  longer  to  process  and,  as  result,  are  captured  at  a  signifi¬ 
cantly  lower  probability  of  packet  intercept  nnder  the  same  93.7%  network  utilization. 
As  a  reminder,  the  worst-case  scenario  packets  are  selected  for  Experiment  3  so  the 
probabililty  of  packet  intercept  represents  the  minimum  probablibilty  of  packet  inter¬ 
cept.  Higher  probabilities  of  packet  intercept  can  be  achieved  with  packets  that  have 
more  favorable  packet  characteristics.  Overall,  the  probability  of  packet  intercept  for 
Wireshark  is  markedly  lower  than  the  TRAPP-2  system  nnder  the  various  network 
ntilizations  of  Experiment  3.  The  defanlt  bnffer  size  for  Wireshark,  which  is  used  for 
this  research,  is  1  MB.  This  is  significantly  greater  than  the  32  KB  First-In-First-Ont 
buffer  used  in  conjnnction  with  the  FPGA’s  Ethernet  controller.  Perhaps  increasing 
the  buffer  size  in  Wireshark  can  produce  more  favorable  results,  but  the  fact  still 
remains  that  the  TRAPP-2  system’s  buffer  is  smaller  and  outperforms  Wireshark. 

Experiment  2  reveals  that  Wireshark  outperforms  the  TRAPP-2  system  when 
there  is  no  additional  network  utilization  added  and  400  packets  flood  the  system.  It 
appears  Wireshark  is  capable  of  handling  a  small  flood  of  packets  of  interest  more 
efficiently  than  the  TRAPP-2  system.  This  is  likely  dne  to  the  large  1  MB  buffer  and 
lack  of  packet  processing  required  by  Wireshark. 

The  results  from  Experiment  4  reveal  that  donbling  the  hash  list  size  increases 
the  packet  processing  time  only  slightly  (an  average  of  0.27%).  Although  the  worst- 
case  scenario  DNS  packet  is  selected  for  the  test,  the  experiment  essentially  measures 
the  speed  of  the  binary  search  algorithm  and  is  independent  of  the  type  of  packet  hash 
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being  processed.  Therefore,  the  results  can  be  extended  and  expected  of  Bit  Torrent 
and  SIP  packet  hashes  as  well.  The  binary  search  algorithm  is  chosen  for  simplicity. 
Implementing  other  data  structures  and  algorithms  could  result  in  faster  hash  lookups. 

4.6  Summary 

This  chapter  presents  the  results  and  analysis  from  the  four  experiments  mea¬ 
suring  packet  processing  time  and  probability  of  packet  intercept.  Statistical  analysis 
of  the  data’s  packet  processing  time  and  probability  of  packet  intercept  is  performed. 
An  overall  analysis  and  discussion  is  presented  at  the  end.  The  most  relevant  re¬ 
sults  show  that  the  TRAPP-2  system  captures  95.56%  of  Bit  Torrent,  20.78%  of  SIP 
INVITE,  37.11%  of  SIP  BYE,  and  91.89%  of  DNS  worst-case  scenario  packets  of  in¬ 
terest  while  under  a  93.7%  network  utilization.  Additionally,  Experiment  4  reveals 
that  each  doubling  of  the  hash  list  size  results  in  a  mean  increase  of  approximately 
16  CPU  cycles. 
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V.  Conclusions 


This  chapter  summarizes  the  overall  goals  and  conclusions  of  the  research.  Sec¬ 
tion  5.1  summarizes  the  results  and  whether  the  goals  and  hypotheses  are  met. 
The  significance  of  the  research  is  presented  in  Section  5.2.  Lastly,  Section  5.3  provides 
recommendations  to  expand  and  progress  the  research  of  the  TRAPP-2  system. 

5.1  Conclusions  of  Research 

5.1.1  Goal  #i.'  Determine  the  paeket  processing  times  for  packets  of  interest. 
The  first  goal  is  to  determine  the  packet  processing  times  for  packets  of  interest.  The 
TRAPP-2  system  must  be  able  to  process  packets  as  quickly  as  possible.  Experiment 
1  reveals  Bit  Torrent  and  DNS  packets  require  the  fewest  CPU  cycles  and  both  types  of 
SIP  packets  require  the  most.  The  TRAPP-2  system  can  process  all  types  of  packets 
under  35,000  CPU  cycles,  thus  meeting  the  goal  and  proving  the  hypothesis. 

5.1.2  Goal  ff2:  Determine  the  probability  of  packet  intercept  under  a  flood  of 
4-00  packets  of  interest.  The  second  goal  of  this  research  is  to  determine  the  prob¬ 
ability  of  packet  intercept  for  a  flood  of  400  packets  of  interest.  Experiment  2  reveals 
that  the  TRAPP-2  system  captures  100%  of  BitTorrent,  86.58%  of  DNS,  22.00%  of 
SIP  BYE,  and  19.92%  of  SIP  INVITE  packets  when  400  packets  are  sent  as  fast  as 
possible,  thus  meeting  the  research  goal.  However,  the  measured  network  utilizations 
vary  significantly  depending  on  the  type  of  packet  being  sent.  The  TRAPP-2  system 
fails  to  capture  over  50%  of  the  SIP  BYE  and  SIP  INVITE  packets,  thus  failing  to 
meet  the  hypothesis.  This  type  of  traffic  is  unrealistic  and  is  simply  meant  to  stress 
the  TRAPP-2  system. 

5.1.3  Goal  443:  Determine  the  probability  of  packet  intercept  under  various 
network  utilizations.  The  third  goal  of  this  research  is  to  determine  the  probability 
of  packet  intercept  for  packets  of  interest  under  various  network  utilizations.  Experi¬ 
ment  3  reveals  that  the  TRAPP-2  system  captures,  with  95%  confidence,  95.56%  of 
BitTorrent,  20.78%  of  SIP  INVITE,  37.11%  of  SIP  BYE,  and  91.89%  of  DNS  packets 
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of  interest  under  a  93.7%  network  utilization.  The  packets  selected  for  the  experi¬ 
ment  are  the  worst-case  scenario,  so  the  reported  probability  of  packet  intercept  is 
the  minimum.  The  93.7%  network  utilization  is  equal  to  937  megabits  per  second. 
These  results  exceed  the  hypothesized  values  and  meet  the  research  goal. 

5.1.4  Goal  444-  Determine  how  the  hash  list  size  affects  packet  processing  time. 

The  fourth  goal  of  this  research  is  to  determine  how  increasing  the  hash  list  size 
affects  the  packet  processing  time.  The  original  hash  list  size  of  1,000  unique  items  is 
doubled  17  times  to  generate  a  hash  list  with  131,072,000  unique  items.  Experiment  4 
reveals  how  each  doubling  of  the  hash  list  exposes  the  logarithmic  nature  of  the  packet 
processing  time  versus  the  number  of  hash  list  items.  The  mean  packet  processing 
time  increases  an  average  of  15.93  CPU  cycles  per  doubling  of  the  hash  list  size.  This 
value  is  less  than  the  hypothesized  value  of  50,  thus  meeting  the  goal  and  proving  the 
hypothesis. 

5.2  Significance  of  Research 

This  research  allows  the  military  and  government  agencies  to  detect  and  track 
malicious  Bit  Torrent,  SIP,  and  DNS  traffic  traversing  networks  at  gigabit  speeds  using 
large  hash  lists.  The  experiments  selected  measure  the  packet  processing  time  and 
probability  of  packet  intercept  for  the  TRAPP-2  system  under  various  conditions.  The 
results  and  analysis  conclude  that  the  TRAPP-2  system  is  capable  of  detecting  and 
tracking  traffic  of  interest  on  a  gigabit  Ethernet  network.  This  research  also  reveals 
how  increasing  the  hash  list  size  affects  the  packet  processing  time  for  DNS  packets. 
Although  DNS  is  the  only  protocol  tested,  the  results  apply  equally  to  Bit  Torrent  hie 
hashes  and  SIP  URI  domains.  This  allows  for  larger  lists  of  known  illegal  Bit  Torrent 
hie  hashes  or  SIP  URIs  of  interest  to  be  used  on  the  TRAPP-2  system. 

The  TRAPP-2  system  is  attractive  to  network  administrators  because  it  is  a 
passive  solution.  The  FPGA  design  allows  for  quick  implementation  onto  a  local  area 
network,  assuming  there  is  a  gateway  switch  with  a  SPAN  port.  In  addition,  if  the 
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TRAPP-2  system  fails,  it  cannot  disrnpt  or  interfere  with  network  traffic  because  it 
is  not  installed  in-line  with  other  network  appliances. 

For  Bit  Torrent  traffic,  the  TRAPP-2  system  aids  law  enforcement  in  the  hght 
against  illegal  file  distribution.  TRAPP-2  can  identify  the  parties  participating  in  an 
illegal  hie  transfer.  The  TRAPP-2  system  can  also  be  used  to  identify  the  accidental  or 
intentional  disclosure  of  sensitive  documents  from  military  and  government  networks 
through  Bit  Torrent  hie  sharing  programs.  The  system  provides  proof  in  the  form  of 
the  logged  packet  which  contains  the  hash  of  the  hie  being  transmitted  and  the  IP 
addresses  of  the  computers  participating. 

The  proliferation  of  Internet  phones  and  VoIP  has  made  tracking  persons  of 
interest  difficult.  The  TRAPP-2  system  aids  law  enforcement  and  intelligence  agencies 
in  identifying  social  networks  and  cells  of  criminals,  terrorists,  and  other  people  of 
interest  using  VoIP  technologies.  By  detecting  SIP  URI  domains  of  interest,  maps  of 
players  and  organizational  hierarchies  can  be  derived  to  aid  investigators. 

Lastly,  the  TRAPP-2  system  aids  network  administrators  in  detecting  poten¬ 
tial  data  exhltration  via  malicious  DNS  traffic.  By  establishing  a  DNS  whitelist  of 
approved  domains,  network  administrators  can  use  the  TRAPP-2  system  to  identify 
potential  abuses  of  DNS.  The  TRAPP-2  system  logs  the  packet,  and  more  impor¬ 
tantly,  the  IP  addresses  of  the  computers  communicating.  This  can  help  investigators 
in  identifying  compromised  computers  and  the  external  IP  addresses  establishing  the 
unauthorized  communication  channels. 

5.3  Recommendations  for  Future  Research 

The  hrst  suggestion  for  future  research  is  to  expand  the  hardware  capabilities  of 
the  ML510  FPGA.  The  board  contains  an  additional  PowerPC  processor  and  gigabit 
Ethernet  controller  that  are  not  used  in  this  research.  Additional  processing,  func¬ 
tions,  and  algorithm  work  can  be  offloaded  to  the  second  processor.  Additionally,  the 
second  processor  can  be  used  to  hash  the  SIP  URIs  and  DNS  domains  using  a  better 


hashing  algorithm  than  sdbm.  The  second  gigabit  Ethernet  controller  can  be  used  as 
a  backup  or  out-of-band  administrative  Ethernet  controller. 

Secondly,  future  research  can  focus  on  using  a  proven  hashing  algorithm  such 
as  SHA-1  or  the  Message-Digest  algorithm  5  (MD5).  For  this  research,  the  sdbm 
hashing  algorithm  is  selected  because  of  its  speed  and  simplicity.  Shortfalls  such  as  a 
minimal  avalanche  effect  and  potential  collisions  are  not  considered.  The  algorithm 
processing  can  reside  on  a  separate  dedicated  processor  as  mentioned  above. 

BitTorrent,  SIP,  and  DNS  are  not  the  only  protocols  that  can  be  abused  or 
have  malicious  intent.  Another  suggestion  is  to  investigate  the  Internet  Relay  Chat 
protocol  used  for  botnet  command  and  control.  The  Hypertext  Transfer  Protocol  is 
another  popular  tunneling  protocol  because  of  its  reliance  on  TCP  port  80,  which  is 
open  in  most  organizations.  The  TRAPP-2  system  can  easily  be  adapted  to  other 
protocols  that  can  be  abused  by  modifying  the  signature  detection  logic. 

Lastly,  detecting  encrypted  and  obfuscated  network  traffic  is  another  area  of 
future  research.  This  research  assumes  that  the  BitTorrent,  SIP,  and  DNS  traffic  is 
not  encrypted  or  obfuscated.  Research  efforts  can  focus  on  decrypting  traffic  on  the 
fly,  perhaps  using  the  other  processor  to  accomplish  this,  while  still  maintaining  the 
system’s  speed. 
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Appendix  A .  Experimental  Data 


This  Appendix  contains  the  raw  data  collected  for  the  experiments.  Section  A.l 
contains  the  data  from  Experiment  1.  Section  A. 2  contains  the  data  from 
Experiment  2.  Section  A. 3  contains  the  data  from  Experiment  3.  Section  A. 4  contains 
the  data  from  Experiment  4. 


A .  1  Results  of  Experiment  1 


Table  A. 2:  CPU  Cycle  Data  for  Experiment  1  Continued. 


SIP  INV  ON  LARGE  WORST 

SIP  INV  ON  SMALL  BEST 

SIP  INV  OFF  LARGE 

SIP  BYE  ON  LARGE  WORST 

Rep.  1 

Rep  2 

Rep  3 

Rep.  1 

Rep  2 

Rep  3 

Rep.  1 

Rep  2 

Rep  3 

Rep.  1 

Rep  2 

Rep  3 

33240 

32776 

32802 

14823 

14735 

14761 

31092 

31092 

31092 

25615 

25347 

25388 

33191 

32809 

32815 

14929 

14815 

14797 

31092 

31092 

31092 

25448 

25374 

25347 

33257 

32896 

32872 

14769 

14822 

14812 

31092 

31092 

31092 

25579 

25347 

25347 

33341 

32779 

32800 

14859 

14769 

14734 

31092 

31092 

31092 

25496 

25347 

25388 

33071 

32856 

32830 

14863 

14783 

14804 

31092 

31092 

31092 

25529 

25347 

25347 

33292 

32857 

32863 

14757 

14758 

14776 

31092 

31092 

31092 

25553 

25370 

25388 

33041 

32780 

32820 

14970 

14774 

14774 

31092 

31092 

31092 

25545 

25347 

25383 

33034 

32847 

32856 

14848 

14782 

14806 

31092 

31092 

31092 

25613 

25380 

25347 

32938 

32832 

32812 

14734 

14761 

14755 

31092 

31092 

31092 

25629 

25347 

25392 

33046 

32805 

32801 

14825 

14807 

14786 

31092 

31092 

31092 

25553 

25380 

25376 

33620 

32825 

32858 

14858 

14783 

14822 

31092 

31092 

31092 

25629 

25376 

25347 

33527 

32800 

32779 

14857 

14734 

14769 

31092 

31092 

31092 

25649 

25384 

25376 

34028 

32862 

32862 

14857 

14820 

14824 

31092 

31092 

31092 

25448 

25347 

25388 

34629 

32907 

32897 

14838 

14761 

14734 

31092 

31092 

31092 

25468 

25374 

25368 

34350 

32816 

32812 

14836 

14760 

14766 

31092 

31092 

31092 

25496 

25368 

25347 

35319 

35268 

35304 

14768 

14816 

14808 

31092 

31092 

31092 

25462 

25370 

25380 

36279 

36194 

36194 

14770 

14735 

14735 

31092 

31092 

31092 

25615 

25376 

25396 

34572 

34571 

34597 

14805 

14851 

14867 

31092 

31092 

31092 

25735 

25374 

25347 

34632 

34647 

34665 

14797 

14808 

14822 

31092 

31092 

31092 

25735 

25368 

25384 

34646 

34596 

34572 

14867 

14734 

14734 

31092 

31092 

31092 

25551 

25347 

25347 

34624 

34632 

34634 

15022 

14810 

14783 

31092 

31092 

31092 

26238 

25384 

25388 

34537 

34706 

34666 

14928 

14734 

14775 

31092 

31092 

31092 

26540 

25347 

25388 

34590 

34600 

34596 

14862 

14734 

14734 

31092 

31092 

31092 

26528 

25368 

25384 

34597 

34655 

34627 

15103 

14782 

14802 

31092 

31092 

31092 

26276 

25347 

25347 

34647 

34590 

34522 

15726 

14771 

14735 

31092 

31092 

31092 

26935 

26311 

26307 

34596 

34567 

34597 

15882 

14823 

14819 

31092 

31092 

31092 

28288 

28600 

28534 

34658 

34641 

34641 

15662 

14835 

14835 

31092 

31092 

31092 

26566 

26508 

26534 

34574 

34534 

34490 

15735 

14769 

14734 

31092 

31092 

31092 

26566 

26510 

26508 

34438 

34620 

34618 

15181 

16279 

16155 

31092 

31092 

31092 

26608 

26566 

26540 

34653 

34670 

34696 

17071 

16833 

16879 

31092 

31092 

31092 

26582 

26550 

26508 

34594 

34596 

34596 

15828 

15752 

15726 

31092 

31092 

31092 

26558 

26576 

26576 

34597 

34601 

34627 

15803 

15828 

15832 

31092 

31092 

31092 

26568 

26576 

26510 

34605 

34390 

34390 

15726 

15728 

15728 

31092 

31092 

31092 

26546 

26602 

26566 

34582 

34597 

34597 

15804 

15831 

15873 

31092 

31092 

31092 

26540 

26604 

26534 

34510 

34397 

34365 

15688 

15799 

15799 

31092 

31092 

31092 

26540 

26576 

26470 

35495 

35555 

35679 

15831 

15753 

15729 

31092 

31092 

31092 

26580 

26508 

26600 

34452 

35158 

35202 

15847 

15812 

15840 

31092 

31092 

31092 

26542 

26508 

26552 

35971 

35872 

35890 

15753 

15753 

15727 

31092 

31092 

31092 

26566 

26552 

26508 

34590 

34596 

34596 

15828 

15752 

15726 

31092 

31092 

31092 

26500 

26534 

26508 

34597 

34627 

34603 

15727 

15802 

15830 

31092 

31092 

31092 

26608 

26508 

26566 

34665 

34590 

34594 

15752 

15752 

15726 

31092 

31092 

31092 

26590 

26534 

26534 

34596 

34597 

34597 

15802 

15831 

15805 

31092 

31092 

31092 

26542 

26550 

26508 

34632 

34665 

34639 

15688 

15799 

15835 

31092 

31092 

31092 

26502 

26508 

26550 

34670 

34610 

34596 

15831 

15727 

15727 

31092 

31092 

31092 

26526 

26536 

26534 

34532 

34620 

34632 

15825 

15844 

15802 

31092 

31092 

31092 

26618 

26550 

26508 

34627 

34676 

34670 

15753 

15759 

15769 

31092 

31092 

31092 

26634 

26444 

26486 

34566 

34598 

34600 

15828 

15726 

15760 

31092 

31092 

31092 

26608 

26508 

26508 

34507 

34563 

34495 

15727 

15828 

15828 

31092 

31092 

31092 

26560 

26508 

26534 

34649 

34642 

34664 

15728 

15726 

15752 

31092 

31092 

31092 

26478 

26602 

26508 

34572 

34597 

34597 

15738 

15807 

15807 

31092 

31092 

31092 

26636 

26594 

26508 
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A. 2  Results  of  Experiment  2 


Table  A. 4:  Packets  Captured  for  Experiment  2. 


Packet  Type 

Packets  Captured  (Events) 

Total  Packets  Captured 

Packets  Sent  (Trials) 

Rep.  1 

Rep.  2 

Rep.  3 

BT  ON  WORST 

400 

400 

400 

1200 

1200 

Wireshark 

400 

400 

400 

1200 

1200 

Average 

Load  (Mbps) 

156.664 

153.579 

153.449 

154.564 

%  of  Max 

15.67% 

15.36% 

15.34% 

15.46% 

SIP  INVITE  ON  LARGE  WORST 

79 

80 

80 

239 

1200 

Wireshark 

400 

400 

400 

1200 

1200 

Average 

Load  (Mbps) 

994.402 

997.901 

992.099 

994.801 

%  of  Max 

99.44% 

99.79% 

99.21% 

99.48% 

SIP  BYE  ON  LARGE  WORST 

88 

88 

88 

264 

1200 

Wireshark 

400 

400 

400 

1200 

1200 

Average 

Load  (Mbps) 

944.62 

952.483 

945.451 

947.518 

%  of  Max 

94.46% 

95.25% 

94.55% 

94.75% 

DNS  OFF  LARGE 

343 

348 

348 

1039 

1200 

Wireshark 

400 

400 

400 

1200 

1200 

Average 

Load  (Mbps) 

242.339 

243.776 

228.405 

238.173 

%  of  Max 

24.23% 

24.38% 

22.84% 

23.82% 
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A .  3  Results  of  Experiment  3 


Table  A. 5:  Packets  Captured  for  Experiment  3,  Utilization  1  (^20.4%). 


Utilization  1  (ci20.4%) 

Packet  Type 

Packets  Gaptured  (Events) 

Total  Packets  Captured 

Packets  Sent  (Trials) 

Rep.  1 

Rep.  2 

Rep.  3 

BT  ON  WORST 

300 

300 

300 

900 

900 

Wireshark 

286 

288 

289 

863 

900 

Average 

Utilization  (Mbps) 

204 

204 

204 

204 

%  of  Max 

20.40% 

20.40% 

20.40% 

20.40% 

SIP  INVITE  ON  LARGE  WORST 

300 

300 

300 

900 

900 

Wireshark 

290 

284 

290 

864 

900 

Average 

Utilization  (Mbps) 

204 

204 

204 

204 

%  of  Max 

20.40% 

20.40% 

20.40% 

20.40% 

SIP  BYE  ON  LARGE  WORST 

300 

300 

300 

900 

900 

Wireshark 

296 

285 

286 

867 

900 

Average 

Utilization  (Mbps) 

204 

204 

204 

204 

%  of  Max 

20.40% 

20.40% 

20.40% 

20.40% 

DNS  OFF  LARGE 

300 

300 

300 

900 

900 

Wireshark 

295 

284 

282 

861 

900 

Average 

Utilization  (Mbps) 

204 

204 

204 

204 

%  of  Max 

20.40% 

20.40% 

20.40% 

20.40% 
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Table  A. 6:  Packets  Captured  for  Experiment  3,  Utilization  2  (^^30.1%). 


Utilization  2  (?s30.10%) 

Packet  Type 

Packets  Gaptured  (Events) 

Total  Packets  Captured 

Packets  Sent  (Trials) 

Rep.  1 

Rep.  2 

Rep.  3 

BT  ON  WORST 

290 

293 

293 

876 

900 

Wireshark 

210 

216 

219 

645 

900 

Average 

Utilization  (Mbps) 

301 

301 

301 

301 

%  of  Max 

30.10% 

30.10% 

30.10% 

30.10% 

SIP  INVITE  ON  LARGE  WORST 

136 

128 

119 

383 

900 

Wireshark 

209 

208 

201 

618 

900 

Average 

Utilization  (Mbps) 

301 

301 

301 

301 

%  of  Max 

30.10% 

30.10% 

30.10% 

30.10% 

SIP  BYE  ON  LARGE  WORST 

192 

190 

189 

571 

900 

Wireshark 

187 

216 

207 

610 

900 

Average 

Utilization  (Mbps) 

301 

301 

301 

301 

%  of  Max 

30.10% 

30.10% 

30.10% 

30.10% 

DNS  OFF  LARGE 

294 

294 

293 

881 

900 

Wireshark 

182 

184 

223 

589 

900 

Average 

Utilization  (Mbps) 

301 

301 

301 

301 

%  of  Max 

30.10% 

30.10% 

30.10% 

30.10% 

Table  A. 7:  Packets  Captured  for  Experiment  3,  Utilization  3  (~40.8%). 


Utilization  3  (ss40.8%) 

Packet  Type 

Packets  Captured  (Events) 

Total  Packets  Captured 

Packets  Sent  (Trials) 

Rep.  1 

Rep.  2 

Rep.  3 

BT  ON  WORST 

290 

297 

283 

870 

900 

Wireshark 

124 

137 

110 

371 

900 

Average 

Utilization  (Mbps) 

408 

408 

408 

408 

%  of  Max 

40.80% 

40.80% 

40.80% 

40.80% 

SIP  INVITE  ON  LARGE  WORST 

88 

98 

97 

283 

900 

Wireshark 

152 

136 

114 

402 

900 

Average 

Utilization  (Mbps) 

408 

408 

408 

408 

%  of  Max 

40.80% 

40.80% 

40.80% 

40.80% 

SIP  BYE  ON  LARGE  WORST 

156 

158 

153 

467 

900 

Wireshark 

123 

131 

124 

378 

900 

Average 

Utilization  (Mbps) 

408 

408 

408 

408 

%  of  Max 

40.80% 

40.80% 

40.80% 

40.80% 

DNS  OFF  LARGE 

287 

292 

289 

868 

900 

Wireshark 

138 

140 

127 

405 

900 

Average 

Utilization  (Mbps) 

408 

408 

408 

408 

%  of  Max 

40.80% 

40.80% 

40.80% 

40.80% 
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Table  A. 8:  Packets  Captured  for  Experiment  3,  Utilization  4  (^49.8%). 


Utilization  4  (si49.8%) 

Packet  Type 

Packets  Gaptured  (Events) 

Total  Packets  Captured 

Packets  Sent  (Trials) 

Rep.  1 

Rep.  2 

Rep.  3 

BT  ON  WORST 

292 

292 

290 

874 

900 

Wireshark 

106 

111 

119 

336 

900 

Average 

Utilization  (Mbps) 

498 

498 

498 

498 

%  of  Max 

49.80% 

49.80% 

49.80% 

49.80% 

SIP  INVITE  ON  LARGE  WORST 

91 

77 

78 

246 

900 

Wireshark 

89 

112 

112 

313 

900 

Average 

Utilization  (Mbps) 

498 

498 

498 

498 

%  of  Max 

49.80% 

49.80% 

49.80% 

49.80% 

SIP  BYE  ON  LARGE  WORST 

145 

143 

126 

414 

900 

Wireshark 

91 

91 

95 

277 

900 

Average 

Utilization  (Mbps) 

498 

498 

498 

498 

%  of  Max 

49.80% 

49.80% 

49.80% 

49.80% 

DNS  OFF  LARGE 

292 

287 

286 

865 

900 

Wireshark 

129 

95 

96 

320 

900 

Average 

Utilization  (Mbps) 

498 

498 

498 

498 

%  of  Max 

49.80% 

49.80% 

49.80% 

49.80% 

Table  A. 9:  Packets  Captured  for  Experiment  3,  Utilization  5  (~60.2%). 


Utilization  5  (ss60.2%) 

Packet  Type 

Packets  Captured  (Events) 

Total  Packets  Captured 

Packets  Sent  (Trials) 

Rep.  1 

Rep.  2 

Rep.  3 

BT  ON  WORST 

285 

286 

291 

862 

900 

Wireshark 

74 

80 

76 

230 

900 

Average 

Utilization  (Mbps) 

602 

602 

602 

602 

%  of  Max 

60.20% 

60.20% 

60.20% 

60.20% 

SIP  INVITE  ON  LARGE  WORST 

97 

79 

74 

250 

900 

Wireshark 

77 

81 

75 

233 

900 

Average 

Utilization  (Mbps) 

602 

602 

602 

602 

%  of  Max 

60.20% 

60.20% 

60.20% 

60.20% 

SIP  BYE  ON  LARGE  WORST 

166 

144 

155 

465 

900 

Wireshark 

97 

103 

80 

280 

900 

Average 

Utilization  (Mbps) 

602 

602 

602 

602 

%  of  Max 

60.20% 

60.20% 

60.20% 

60.20% 

DNS  OFF  LARGE 

266 

278 

275 

819 

900 

Wireshark 

89 

95 

99 

283 

900 

Average 

Utilization  (Mbps) 

602 

602 

602 

602 

%  of  Max 

60.20% 

60.20% 

60.20% 

60.20% 
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Table  A. 10:  Packets  Captured  for  Experiment  3,  Utilization  6  (~71.4%). 


Utilization  6  (?5s71.4%) 

Packet  Type 

Packets  Captured  (Events) 

Total  Packets  Captured 

Packets  Sent  (Trials) 

Rep.  1 

Rep.  2 

Rep.  3 

BT  ON  WORST 

285 

278 

288 

851 

900 

Wireshark 

77 

76 

59 

212 

900 

Average 

Utilization  (Mbps) 

714 

714 

714 

714 

%  of  Max 

71.40% 

71.40% 

71.40% 

71.40% 

SIP  INVITE  ON  LARGE  WORST 

75 

76 

76 

227 

900 

Wireshark 

67 

63 

73 

203 

900 

Average 

Utilization  (Mbps) 

714 

714 

714 

714 

%  of  Max 

71.40% 

71.40% 

71.40% 

71.40% 

SIP  BYE  ON  LARGE  WORST 

146 

136 

142 

424 

900 

Wireshark 

85 

71 

74 

230 

900 

Average 

Utilization  (Mbps) 

714 

714 

714 

714 

%  of  Max 

71.40% 

71.40% 

71.40% 

71.40% 

DNS  OFF  LARGE 

279 

270 

279 

828 

900 

Wireshark 

71 

69 

66 

206 

900 

Average 

Utilization  (Mbps) 

714 

714 

714 

714 

%  of  Max 

71.40% 

71.40% 

71.40% 

71.40% 

Table  A. 11:  Packets  Captured  for  Experiment  3,  Utilization  7  (~81.8%). 


Utilization  7  (si81.8%) 

Packet  Type 

Packets  Captured  (Events) 

Total  Packets  Captured 

Packets  Sent  (Trials) 

Rep.  1 

Rep.  2 

Rep.  3 

BT  ON  WORST 

284 

286 

292 

862 

900 

Wireshark 

72 

59 

57 

188 

900 

Average 

Utilization  (Mbps) 

818 

818 

818 

818 

%  of  Max 

81.80% 

81.80% 

81.80% 

81.80% 

SIP  INVITE  ON  LARGE  WORST 

63 

64 

82 

209 

900 

Wireshark 

56 

77 

65 

198 

900 

Average 

Utilization  (Mbps) 

818 

818 

818 

818 

%  of  Max 

81.80% 

81.80% 

81.80% 

81.80% 

SIP  BYE  ON  LARGE  WORST 

152 

144 

113 

409 

900 

Wireshark 

73 

56 

50 

179 

900 

Average 

Utilization  (Mbps) 

818 

818 

818 

818 

%  of  Max 

81.80% 

81.80% 

81.80% 

81.80% 

DNS  OFF  LARGE 

268 

265 

269 

802 

900 

Wireshark 

75 

79 

71 

225 

900 

Average 

Utilization  (Mbps) 

818 

818 

818 

818 

%  of  Max 

81.80% 

81.80% 

81.80% 

81.80% 
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Table  A.  12:  Packets  Captured  for  Experiment  3,  Utilization  8  (~93.7%). 


Utilization  8  (Max  ss  93.7%) 

Packet  Type 

Packets  Gaptured  (Events) 

Total  Packets  Captured 

Packets  Sent  (Trials) 

Rep.  1 

Rep.  2 

Rep.  3 

BT  ON  WORST 

287 

289 

284 

860 

900 

Wireshark 

54 

48 

53 

155 

900 

Average 

Utilization  (Mbps) 

937 

937 

937 

937 

%  of  Max 

93.70% 

93.70% 

93.70% 

93.70% 

SIP  INVITE  ON  LARGE  WORST 

72 

58 

57 

187 

900 

Wireshark 

53 

53 

41 

147 

900 

Average 

Utilization  (Mbps) 

937 

937 

937 

937 

%  of  Max 

93.70% 

93.70% 

93.70% 

93.70% 

SIP  BYE  ON  LARGE  WORST 

117 

106 

111 

334 

900 

Wireshark 

53 

46 

44 

143 

900 

Average 

Utilization  (Mbps) 

937 

937 

937 

937 

%  of  Max 

93.70% 

93.70% 

93.70% 

93.70% 

DNS  OFF  LARGE 

273 

275 

279 

827 

900 

Wireshark 

53 

59 

50 

162 

900 

Average 

Utilization  (Mbps) 

937 

937 

937 

937 

%  of  Max 

93.70% 

93.70% 

93.70% 

93.70% 
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A. 4-  Results  of  Experiment  4 


Table  A.  13:  CPU  Cycle  Data  for  Experiment  4. 


List  Size 

2,000 

4,000 

8,000 

16,000 

Packet 

Rep  1 

Rep  2 

Rep  3 

Rep  1 

Rep  2 

Rep  3 

Rep  1 

Rep  2 

Rep  3 

Rep  1 

Rep  2 

Rep  3 

1 

5646 

5759 

5636 

5662 

5662 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

2 

5748 

5646 

5636 

5764 

5738 

5650 

5754 

5743 

5666 

5770 

5754 

5682 

3 

5646 

5722 

5636 

5662 

5662 

5650 

5678 

5678 

5666 

5743 

5742 

5682 

4 

5748 

5729 

5636 

5764 

5775 

5650 

5743 

5754 

5666 

5759 

5770 

5682 

5 

5646 

5722 

5636 

5662 

5662 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

6 

5768 

5646 

5636 

5764 

5738 

5650 

5754 

5791 

5666 

5743 

5770 

5682 

7 

5646 

5722 

5636 

5662 

5662 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

8 

5768 

5646 

5636 

5764 

5738 

5650 

5738 

5738 

5666 

5770 

5770 

5682 

9 

5646 

5722 

5636 

5662 

5675 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

10 

5744 

5646 

5636 

5764 

5790 

5650 

5738 

5756 

5666 

5743 

5759 

5682 

11 

5646 

5722 

5636 

5662 

5662 

5650 

5717 

5678 

5666 

5694 

5694 

5682 

12 

5740 

5646 

5636 

5764 

5738 

5650 

5754 

5754 

5666 

5770 

5759 

5682 

13 

5679 

5722 

5636 

5662 

5662 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

14 

5803 

5646 

5636 

5764 

5738 

5650 

5771 

5754 

5666 

5759 

5824 

5682 

15 

5691 

5722 

5636 

5662 

5662 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

16 

5768 

5698 

5636 

5776 

5738 

5650 

5754 

5779 

5666 

5743 

5811 

5682 

17 

5646 

5735 

5636 

5662 

5714 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

18 

5768 

5646 

5636 

5764 

5738 

5650 

5754 

5816 

5666 

5823 

5840 

5682 

19 

5646 

5722 

5636 

5662 

5662 

5650 

5678 

5678 

5666 

5694 

5745 

5682 

20 

5740 

5646 

5636 

5764 

5738 

5650 

5754 

5754 

5666 

5743 

5807 

5682 

21 

5646 

5722 

5636 

5662 

5662 

5650 

5678 

5742 

5666 

5694 

5694 

5682 

22 

5740 

5646 

5636 

5764 

5738 

5650 

5754 

5878 

5666 

5754 

5770 

5682 

23 

5646 

5780 

5636 

5662 

5662 

5650 

5678 

5678 

5666 

5694 

5746 

5682 

24 

5748 

5646 

5636 

5764 

5738 

5650 

5743 

5775 

5666 

5759 

5902 

5682 

25 

5646 

5930 

5636 

5662 

5662 

5650 

5678 

5678 

5666 

5694 

5787 

5682 

26 

5748 

5646 

5636 

5764 

5738 

5650 

5743 

5846 

5666 

5770 

5796 

5682 

27 

5646 

5722 

5636 

5662 

5890 

5650 

5678 

5726 

5666 

5694 

5726 

5682 

28 

5768 

5846 

5636 

5764 

5935 

5650 

5793 

5754 

5666 

5743 

6023 

5682 

29 

5646 

5814 

5636 

5699 

5879 

5650 

5678 

5698 

5666 

5694 

5694 

5682 

30 

5748 

5698 

5636 

5764 

5856 

5650 

5818 

6006 

5666 

5770 

5946 

5682 

31 

5646 

5706 

5636 

5662 

5775 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

32 

5740 

5790 

5636 

5764 

5738 

5650 

5754 

5806 

5666 

5827 

5770 

5682 

33 

5646 

6090 

5636 

5662 

5662 

5650 

5678 

5823 

5666 

5694 

5694 

5682 

34 

5768 

5646 

5636 

5764 

5894 

5650 

5727 

5966 

5666 

5809 

5770 

5682 

35 

5646 

5722 

5636 

5693 

5662 

5650 

5678 

5678 

5666 

5694 

5775 

5682 

36 

5768 

5646 

5636 

5764 

5738 

5650 

5754 

5754 

5666 

5759 

5770 

5682 

37 

5646 

5722 

5636 

5662 

5662 

5650 

5678 

5678 

5666 

5694 

5735 

5682 

38 

5773 

5646 

5636 

5764 

5799 

5650 

5754 

5754 

5666 

5759 

5819 

5682 

39 

5646 

5792 

5636 

5662 

5714 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

40 

5748 

5646 

5636 

5764 

5738 

5650 

5743 

5754 

5666 

5816 

5770 

5682 

41 

5646 

5722 

5636 

5662 

5662 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

42 

5768 

5646 

5636 

5801 

5738 

5650 

5743 

5754 

5666 

5770 

5783 

5682 

43 

5646 

5748 

5636 

5662 

5675 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

44 

5768 

5703 

5636 

5764 

5738 

5650 

5727 

5754 

5666 

5770 

5770 

5682 

45 

5646 

5722 

5636 

5662 

5679 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

46 

5748 

5646 

5636 

5784 

5738 

5650 

5743 

5754 

5666 

5759 

5780 

5682 

47 

5646 

5722 

5636 

5662 

5662 

5650 

5678 

5678 

5666 

5694 

5731 

5682 

48 

5740 

5646 

5636 

5764 

5738 

5650 

5754 

5754 

5666 

5743 

5770 

5682 

49 

5646 

5722 

5636 

5705 

5662 

5650 

5678 

5678 

5666 

5694 

5694 

5682 

50 

5740 

5646 

5636 

5764 

5738 

5650 

5777 

5754 

5666 

5770 

5770 

5682 

Table  A.  14:  CPU  Cycle  Data  for  Experiment  4  Continued. 


1  32,000 

64,000 

128,000 

256,000  1 

Rep  1 

Rep  2 

Rep  3 

Rep  1 

Rep  2 

Rep  3 

Rep  1 

Rep  2 

Rep  3 

Rep  1 

Rep  2 

Rep  3 

5710 

5710 

5698 

5775 

5726 

5714 

5742 

5783 

5738 

5766 

5766 

5754 

5786 

5775 

5698 

5802 

5791 

5714 

5815 

5814 

5738 

5835 

5835 

5754 

5710 

5758 

5698 

5726 

5741 

5717 

5742 

5750 

5738 

5766 

5766 

5754 

5775 

5775 

5698 

5819 

5863 

5718 

5826 

5814 

5738 

5869 

5887 

5754 

5710 

5710 

5698 

5726 

5726 

5714 

5742 

5750 

5738 

5766 

5823 

5754 

5775 

5775 

5698 

5791 

5802 

5714 

5815 

5830 

5738 

5835 

5846 

5754 

5710 

5710 

5698 

5733 

5726 

5714 

5742 

5750 

5738 

5766 

5766 

5754 

5828 

5775 

5698 

5791 

5802 

5714 

5803 

5819 

5738 

5819 

5835 

5754 

5710 

5710 

5698 

5726 

5726 

5714 

5742 

5750 

5738 

5766 

5766 

5754 

5759 

5828 

5698 

5835 

5837 

5714 

5826 

5817 

5738 

5846 

5846 

5754 

5733 

5710 

5698 

5726 

5726 

5714 

5742 

5802 

5738 

5811 

5766 

5754 

5794 

5786 

5698 

5845 

5791 

5714 

5815 

5830 

5738 

5835 

5835 

5754 

5710 

5710 

5698 

5726 

5726 

5714 

5742 

5750 

5738 

5766 

5766 

5754 

5791 

5775 

5698 

5791 

5791 

5714 

5826 

5914 

5738 

5846 

5835 

5754 

5710 

5710 

5698 

5726 

5726 

5714 

5742 

5818 

5738 

5766 

5766 

5754 

5775 

5775 

5698 

5791 

5791 

5714 

5815 

5904 

5738 

5835 

5846 

5754 

5710 

5810 

5698 

5726 

5726 

5714 

5742 

5839 

5738 

5766 

5801 

5754 

5786 

5795 

5698 

5791 

5791 

5714 

5826 

5927 

5738 

5819 

5835 

5754 

5710 

5710 

5698 

5726 

5778 

5714 

5742 

5854 

5738 

5766 

5818 

5754 

5786 

5823 

5698 

5791 

5811 

5714 

5815 

5830 

5738 

5846 

5835 

5754 

5710 

5710 

5698 

5726 

5882 

5714 

5742 

6046 

5738 

5766 

5934 

5754 

5775 

5796 

5698 

5791 

5797 

5714 

5826 

5922 

5738 

5846 

5914 

5754 

5710 

5762 

5698 

5726 

5726 

5714 

5742 

5834 

5738 

5766 

5890 

5754 

5835 

5882 

5698 

5802 

5886 

5714 

5815 

5856 

5738 

5835 

5846 

5754 

5710 

5810 

5698 

5726 

5890 

5714 

5742 

5818 

5738 

5823 

5905 

5757 

5775 

5920 

5698 

5791 

5855 

5714 

5826 

5962 

5738 

5835 

6179 

5754 

5710 

5846 

5698 

5726 

5726 

5714 

5742 

5750 

5738 

5766 

5766 

5754 

5775 

5796 

5698 

5775 

6202 

5714 

5815 

5882 

5738 

5819 

6062 

5754 

5717 

5882 

5698 

5773 

5778 

5714 

5742 

5750 

5738 

5766 

5818 

5754 

5775 

5972 

5698 

5802 

5802 

5714 

5826 

5839 

5738 

5846 

5995 

5754 

5710 

5710 

5698 

5726 

5990 

5714 

5742 

5750 

5738 

5766 

5862 

5754 

5811 

5850 

5698 

5791 

5791 

5714 

5826 

5830 

5738 

5846 

5835 

5754 

5710 

5710 

5698 

5726 

5726 

5714 

5742 

5750 

5738 

5766 

5818 

5754 

5775 

5786 

5698 

5791 

5825 

5714 

5826 

5845 

5738 

5846 

5846 

5754 

5710 

5710 

5698 

5726 

5726 

5714 

5742 

5799 

5738 

5766 

5766 

5754 

5786 

5786 

5698 

5786 

5802 

5714 

5815 

5830 

5738 

5819 

5846 

5754 

5710 

5710 

5698 

5726 

5726 

5714 

5742 

5750 

5738 

5766 

5766 

5754 

5775 

5786 

5698 

5786 

5802 

5714 

5826 

5830 

5738 

5830 

5846 

5754 

5710 

5749 

5698 

5726 

5726 

5714 

5742 

5783 

5738 

5766 

5766 

5754 

5786 

5786 

5698 

5802 

5802 

5714 

5826 

5830 

5738 

5846 

5883 

5754 

5710 

5710 

5698 

5726 

5726 

5714 

5742 

5750 

5738 

5803 

5766 

5754 

5823 

5786 

5698 

5806 

5802 

5714 

5866 

5872 

5738 

5846 

5846 

5754 

5710 

5710 

5698 

5726 

5765 

5714 

5742 

5750 

5738 

5766 

5766 

5754 

5786 

5786 

5698 

5791 

5802 

5714 

5826 

5830 

5738 

5846 

5846 

5754 

5710 

5710 

5698 

5726 

5726 

5714 

5742 

5750 

5738 

5766 

5807 

5754 

5811 

5786 

5698 

5802 

5802 

5714 

5841 

5830 

5738 

5819 

5846 

5754 

5710 

5710 

5698 

5726 

5726 

5714 

5742 

5750 

5738 

5766 

5766 

5754 

5775 

5786 

5698 

5802 

5802 

5714 

5826 

5830 

5738 

5899 

5846 

5754 

5710 

5710 

5698 

5726 

5749 

5714 

5742 

5750 

5738 

5766 

5766 

5754 

5786 

5786 

5698 

5802 

5802 

5714 

5857 

5830 

5738 

5846 

5846 

5754 
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Table  A.  15:  CPU  Cycle  Data  for  Experiment  4  Continued. 


1  512,000 

1,024,000 

2,048,000 

4,096,000  1 

Rep  1 

Rep  2 

Rep  3 

Rep  1 

Rep  2 

Rep  3 

Rep  1 

Rep  2 

Rep  3 

Rep  1 

Rep  2 

Rep  3 

5782 

5782 

5770 

5798 

5798 

5786 

5851 

5814 

5802 

5834 

5834 

5822 

5847 

5851 

5770 

5878 

5867 

5786 

5894 

5954 

5802 

5914 

5909 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5855 

5814 

5802 

5834 

5834 

5822 

5847 

5914 

5770 

5867 

5919 

5786 

5883 

5878 

5802 

5903 

5951 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

5834 

5822 

5847 

5862 

5770 

5867 

5878 

5786 

5883 

5878 

5802 

5903 

5887 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

5834 

5822 

5831 

5885 

5770 

5851 

5878 

5786 

5867 

5894 

5802 

5887 

5914 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

6534 

5822 

5893 

5862 

5770 

5878 

5867 

5786 

5894 

5883 

5802 

5914 

5941 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

5882 

5822 

5847 

5851 

5770 

5878 

5878 

5786 

5883 

5883 

5802 

5903 

5898 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

5834 

5822 

5847 

5851 

5770 

5867 

5867 

5786 

5894 

5935 

5802 

5914 

5966 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

5834 

5822 

5847 

5851 

5770 

5867 

5919 

5786 

5894 

5950 

5802 

5914 

5914 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

5902 

5822 

5842 

5862 

5770 

5867 

5867 

5786 

5878 

6033 

5802 

5887 

6022 

5822 

5782 

5886 

5770 

5798 

5854 

5786 

5814 

6414 

5802 

5834 

5938 

5822 

5858 

5885 

5770 

5867 

5878 

5786 

5929 

5883 

5802 

5914 

5914 

5822 

5782 

5834 

5770 

5798 

6462 

5786 

5814 

5866 

5802 

5834 

5886 

5822 

5858 

5919 

5770 

5867 

5919 

5786 

5894 

5894 

5802 

5914 

6055 

5822 

5782 

6315 

5770 

5798 

5798 

5786 

5814 

5942 

5802 

5834 

5918 

5822 

5847 

5914 

5770 

5878 

5930 

5786 

5883 

5894 

5802 

5903 

5940 

5822 

5782 

5874 

5770 

5798 

5902 

5786 

5814 

5886 

5802 

5834 

5902 

5822 

5847 

5851 

5770 

5867 

5867 

5786 

5894 

5972 

5802 

5914 

6010 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5962 

5802 

5834 

5834 

5822 

5847 

6078 

5770 

5851 

6282 

5786 

5883 

6018 

5802 

5887 

5966 

5822 

5782 

5843 

5770 

5798 

5850 

5786 

5814 

5814 

5802 

5834 

5834 

5822 

5858 

6011 

5770 

5927 

5878 

5786 

5894 

6047 

5802 

5914 

5914 

5822 

5782 

5878 

5770 

5798 

5850 

5786 

5814 

5914 

5802 

5834 

5834 

5822 

5858 

5862 

5770 

5878 

5878 

5786 

5894 

5883 

5802 

5914 

5951 

5822 

5782 

5834 

5770 

5798 

5798 

5786 

5814 

5866 

5802 

5834 

5834 

5822 

5842 

5911 

5770 

5867 

5878 

5786 

5894 

5894 

5802 

5914 

5914 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

5834 

5822 

5842 

5899 

5770 

5862 

5931 

5786 

5919 

5894 

5802 

5903 

5914 

5822 

5782 

5782 

5770 

5811 

5798 

5786 

5814 

5814 

5802 

5834 

5834 

5822 

5858 

5916 

5770 

5862 

5878 

5786 

5894 

5894 

5802 

5914 

5967 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

5863 

5822 

5892 

5862 

5770 

5896 

5878 

5786 

5894 

5894 

5802 

5914 

5914 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

5834 

5822 

5858 

5862 

5770 

5878 

5878 

5786 

5904 

5894 

5802 

5914 

5914 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

5834 

5822 

5858 

5862 

5770 

5867 

5878 

5786 

5894 

5894 

5802 

5914 

5914 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

5834 

5822 

5858 

5862 

5770 

5878 

5928 

5786 

5883 

5894 

5802 

5903 

5914 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5865 

5881 

5822 

5858 

5862 

5770 

5878 

5878 

5786 

5883 

5894 

5802 

5903 

5914 

5822 

5782 

5782 

5770 

5798 

5798 

5786 

5814 

5814 

5802 

5834 

5834 

5822 

5847 

5862 

5770 

5878 

5878 

5786 

5883 

5894 

5802 

5914 

5914 

5822 
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Table  A.  16:  CPU  Cycle  Data  for  Experiment  4  Continued. 


1  8,192,000 

16,384,000 

32,768,000 

65,536,000  1 

Rep  1 

Rep  2 

Rep  3 

Rep  1 

Rep  2 

Rep  3 

Rep  1 

Rep  2 

Rep  3 

Rep  1 

Rep  2 

Rep  3 

5850 

5902 

5839 

5866 

5866 

5854 

5882 

6746 

5870 

5902 

5954 

5890 

5930 

5919 

5838 

5946 

5935 

5854 

6003 

5951 

5870 

5971 

5974 

5890 

5850 

5850 

5838 

5866 

5866 

5854 

5882 

5882 

5870 

5902 

5902 

5890 

5919 

5919 

5838 

5935 

6679 

5854 

5951 

5951 

5870 

5982 

6022 

5890 

5850 

5881 

5838 

5866 

5866 

5854 

5882 

5919 

5870 

5902 

5902 

5890 

5919 

6643 

5838 

5935 

5935 

5854 

5951 

5951 

5870 

5971 

6124 

5890 

5850 

5850 

5838 

5866 

5866 

5854 

5882 

5891 

5870 

5902 

5902 

5890 

5903 

5932 

5838 

5919 

5946 

5854 

5935 

6004 

5870 

5971 

5974 

5890 

5850 

5930 

5838 

5866 

5918 

5854 

5882 

5938 

5870 

5902 

5954 

5890 

5930 

5914 

5838 

5946 

5943 

5854 

5962 

5946 

5870 

5971 

5963 

5890 

5850 

5902 

5838 

5866 

5918 

5854 

5882 

5990 

5870 

5902 

6120 

5890 

5919 

5914 

5838 

5961 

5930 

5854 

5951 

5946 

5870 

5971 

5963 

5890 

5850 

5850 

5838 

5866 

5871 

5854 

5882 

5882 

5870 

5902 

5902 

5890 

5930 

5982 

5838 

5946 

5998 

5854 

5962 

6014 

5870 

5982 

6000 

5890 

5850 

5850 

5838 

5915 

5866 

5854 

5882 

5882 

5870 

5902 

5970 

5890 

5930 

5987 

5838 

5946 

5946 

5854 

5962 

5962 

5870 

5982 

6027 

5890 

5850 

5918 

5838 

5866 

5934 

5854 

5882 

5954 

5870 

5902 

5902 

5890 

5963 

6038 

5838 

5935 

6054 

5854 

5999 

6074 

5870 

5971 

6092 

5980 

5850 

5954 

5838 

5911 

5970 

5854 

5882 

5986 

5870 

5902 

5902 

5890 

5988 

5993 

5838 

5935 

5946 

5854 

5951 

5962 

5870 

5982 

6158 

5890 

5850 

5902 

5838 

5866 

5918 

5854 

5882 

5934 

5870 

5902 

5902 

5890 

5952 

6022 

5838 

5946 

6106 

5854 

5962 

6080 

5870 

5982 

6004 

5890 

5850 

5997 

5838 

5866 

6014 

5854 

5921 

5966 

5870 

5902 

5958 

5890 

5919 

5956 

5838 

5935 

5972 

5854 

5951 

5988 

5870 

5971 

5974 

5890 

5850 

5918 

5838 

5866 

5934 

5854 

5882 

5954 

5870 

5902 

5902 

5890 

5930 

6026 

5838 

5984 

6042 

5854 

5962 

6062 

5870 

5971 

5974 

5890 

5850 

5850 

5838 

5866 

5866 

5854 

5882 

5882 

5870 

5902 

5902 

5890 

5930 

5982 

5838 

5919 

5998 

5854 

6002 

6014 

5870 

5971 

6009 

5890 

5850 

5850 

5838 

5866 

5903 

5854 

5882 

5882 

5870 

5959 

5902 

5890 

5930 

5930 

5838 

5983 

5946 

5854 

5962 

5962 

5870 

5993 

5974 

5890 

5850 

5887 

5838 

5866 

5866 

5854 

5882 

5931 

5870 

5902 

5902 

5890 

5930 

5930 

5838 

5946 

5946 

5854 

5962 

5962 

5870 

5971 

5974 

5890 

5850 

5850 

5838 

5866 

5866 

5854 

5882 

5882 

5870 

5902 

5902 

5890 

5930 

5930 

5838 

5946 

5946 

5854 

5962 

6011 

5870 

5971 

5974 

5890 

5850 

5850 

5838 

5866 

5866 

5854 

5882 

5882 

5870 

5902 

5902 

5890 

5919 

5930 

5838 

5935 

5946 

5854 

5951 

5962 

5870 

5982 

5974 

5890 

5850 

5850 

5838 

5866 

5866 

5854 

5882 

5882 

5870 

5902 

5902 

5890 

5930 

5967 

5838 

5930 

5946 

5854 

5983 

5962 

5870 

5982 

5974 

5890 

5850 

5850 

5838 

5866 

5866 

5854 

5882 

5882 

5870 

5902 

5902 

5890 

5930 

5930 

5838 

5946 

5957 

5854 

5962 

5962 

5870 

5971 

5974 

5890 

5850 

5850 

5838 

5866 

5866 

5854 

5882 

5882 

5870 

5902 

5943 

5890 

5930 

5930 

5838 

5946 

5946 

5854 

5962 

5962 

5870 

5982 

5974 

5890 

5850 

5850 

5838 

5866 

5866 

5854 

5882 

5882 

5870 

5902 

5902 

5890 

5953 

5930 

5838 

5946 

5946 

5854 

5962 

6011 

5870 

6031 

5974 

5890 

5907 

5850 

5838 

5866 

5866 

5854 

5882 

5882 

5870 

5902 

5902 

5890 

5953 

5930 

5838 

5978 

5946 

5854 

5951 

5962 

5870 

5971 

5974 

5890 

5850 

5887 

5838 

5866 

5866 

5854 

5882 

5882 

5870 

5902 

5902 

5890 

5919 

5930 

5838 

5967 

6008 

5854 

5951 

5962 

5870 

5971 

5974 

5890 

5850 

5850 

5838 

5866 

5866 

5854 

5882 

5923 

5870 

5902 

5902 

5890 

5919 

5930 

5838 

5946 

5946 

5854 

5951 

5962 

5870 

5971 

6016 

5996 
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Table  A. 17: 


CPU  Cycle  Data  for  Experiment  4  Continued. 


131,072,000  1 

Rep  1 

Rep  2 

Rep  3 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5999 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

6051 

5971 

5906 

5918 

5918 

5906 

6004 

5971 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5987 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5943 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

6063 

6070 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5986 

5906 

5951 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5994 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

5971 

5906 

5918 

5918 

5906 

5998 

6005 

5906 
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Appendix  B.  Pilot  Test  Data 


This  appendix  contains  the  pilot  test  data  used  to  make  decisions  in  designing 
the  TRAPP-2  system.  Section  B.1.1  investigates  the  BRAM  versus  SDRAM 
memory  scheme  processing  times.  Section  B.1.2  determines  the  additional  CPU  cycles 
required  to  detect  DNS  packets.  Section  B.1.3  compares  the  number  of  CPU  cycles 
required  to  sdbm  hash  the  smallest  and  largest  SIP/DNS  domains.  Section  B.1.4 
compares  the  number  of  CPU  cycles  required  to  copy  the  smallest  and  largest  packet 
sizes  into  a  software  buffer. 

B.l  Results  of  Pilot  Studies 

B.1.1  BRAM  versus  SDRAM  Memory  Scheme.  Table  B.l  contains  the 
number  of  CPU  cycles  required  to  process  a  SIP  packet  for  the  BRAM  and  SDRAM 
memory  configurations.  For  each  configuration,  50  packets  are  sent  to  the  apparatus 
and  the  number  of  CPU  cycles  required  to  process  the  packet  are  recorded  in  the  table. 
The  SDRAM  memory  scheme  averages  16,076  CPU  cycles,  and  the  BRAM  memory 
scheme  averages  15,299  CPU  cycles.  The  average  difference  between  the  memory 
schemes  is  777  CPU  cycles.  The  design  decision  is  to  accept  the  average  increase  of 
777  CPU  cycles  for  the  larger  addressable  memory  range,  thus  the  SDRAM  memory 
scheme  is  selected. 
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Table  B.l: 


CPU  Cycles  Used  to  Process  a  SIP  Packet. 


Packet 

BRAM 

SDRAM 

1 

19554 

21119 

2 

15304 

16037 

3 

15227 

15949 

4 

15367 

15979 

5 

15272 

15910 

6 

15296 

16007 

7 

15259 

15959 

8 

15354 

15989 

9 

15320 

15978 

10 

15324 

15921 

11 

15147 

16012 

12 

15321 

16019 

13 

15337 

15911 

14 

15274 

15915 

15 

15196 

15977 

16 

15397 

15958 

17 

15275 

15933 

18 

15242 

15973 

19 

15256 

16025 

20 

15361 

15992 

21 

15117 

16019 

22 

15158 

15911 

23 

14876 

16009 

24 

14989 

15938 

25 

15289 

15979 

26 

15406 

16065 

27 

15409 

15911 

28 

15402 

15943 

29 

15179 

15910 

30 

14770 

15917 

31 

14789 

16005 

32 

14854 

16005 

33 

15441 

15938 

34 

15334 

15984 

35 

15705 

16013 

36 

15947 

15955 

37 

15120 

15989 

38 

15056 

15988 

39 

15057 

16019 

40 

15111 

15929 

41 

15120 

15921 

42 

15044 

15992 

43 

15057 

15961 

44 

15111 

15981 

45 

15120 

16021 

46 

15056 

15968 

47 

15057 

16019 

48 

15111 

15959 

49 

15121 

15985 

50 

15041 

16025 

Average 

15,299 

16,076 

104 


B.1.2  DNS  Packet  Detection.  Table  B.2  contains  the  number  of  cycles 
required  to  identify  a  DNS  packet.  50  packets  are  sent  to  the  TRAPP-2  system,  and 
the  number  of  CPU  cycles  required  to  identify  a  DNS  packet  is  recorded  in  the  table. 
The  system  averages  23  CPU  cycles  to  identify  a  DNS  packet. 

Table  B.2:  CPU  Cycles  Used  to  Identify  a  DNS  Packet. 


Packet 

CPU  Cycles 

1 

23 

2 

23 

3 

23 

4 

23 

5 

23 

6 

23 

7 

23 

8 

23 

9 

23 

10 

23 

11 

23 

12 

23 

13 

23 

14 

23 

15 

23 

16 

23 

17 

23 

18 

23 

19 

23 

20 

23 

21 

23 

22 

23 

23 

23 

24 

23 

25 

23 

26 

23 

27 

23 

28 

23 

29 

23 

30 

23 

31 

23 

32 

23 

33 

23 

34 

23 

35 

23 

36 

23 

37 

23 

38 

23 

39 

23 

40 

23 

41 

23 

42 

23 

43 

23 

44 

23 

45 

23 

46 

23 

47 

23 

48 

23 

49 

23 

50 

23 

Average 

23 
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B.1.3  sdhm  Hashing  Times.  Table  B.3  contains  the  number  of  CPU  cycles 
required  to  process  the  smallest  and  largest  SIP  domain  address.  50  packets  with 
a  six-character  domain  and  50  packets  with  a  212-character  domain  are  sent  to  the 
TRAPP-2  system;  the  number  of  CPU  cycles  required  to  process  the  packets  are 
recorded  in  the  table.  The  system  averages  86  CPU  cycles  to  sdbm  hash  a  six- 
character  domain  and  1195  to  sdbm  hash  a  212-character  domain. 
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B.1.4  Packet  Size  Transfer  Times.  Table  B.4  below  contains  the  number  of 
CPU  cycles  required  to  transfer  a  packet  from  the  TRAPP-2  system  into  the  software 
buffer.  50  packets  with  a  size  of  67  bytes  and  50  packets  with  a  size  of  1,500  bytes 
are  sent  to  the  TRAPP-2  system;  the  number  of  CPU  cycles  required  to  process  the 
packets  are  recorded  in  the  table.  The  system  averages  999  CPU  cycles  to  transfer  a 
67  byte  packet  and  18,112  CPU  cycles  to  transfer  a  1,500  byte  packet. 
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Table  B.4: 


CPU  Cycles  Used  to  Copy  Smallest  versus  Largest  Packet. 


Packet 

67-Byte  Packet 

1500-Byte  Packet 

1 

999 

18112 

2 

999 

18112 

3 

999 

18112 

4 

999 

18112 

5 

999 

18112 

6 

999 

18112 

7 

999 

18112 

8 

999 

18112 

9 

999 

18112 

10 

999 

18112 

11 

999 

18112 

12 

999 

18112 

13 

999 

18112 

14 

999 

18112 

15 

999 

18112 

16 

999 

18112 

17 

999 

18112 

18 

999 

18112 

19 

999 

18112 

20 

999 

18112 

21 

999 

18112 

22 

999 

18112 

23 

999 

18112 

24 

999 

18112 

25 

999 

18112 

26 

999 

18112 

27 

999 

18112 

28 

999 

18112 

29 

999 

18112 

30 

999 

18112 

31 

999 

18112 

32 

999 

18112 

33 

999 

18112 

34 

999 

18112 

35 

999 

18112 

36 

999 

18112 

37 

999 

18112 

38 

999 

18112 

39 

999 

18112 

40 

999 

18112 

41 

999 

18112 

42 

999 

18112 

43 

999 

18112 

44 

999 

18112 

45 

999 

18112 

46 

999 

18112 

47 

999 

18112 

48 

999 

18112 

49 

999 

18112 

50 

999 

18112 

Average 

999 

18112 
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Appendix  C.  Constructing  the  TRAPP-2  System  Hardware 

This  appendix  contains  the  step-by-step  guide  to  constructing  the  hardware  por¬ 
tion  of  the  TRAPP-2  system.  Section  C.l  provides  a  description  of  the  hard¬ 
ware  used  in  the  TRAPP-2  system.  Section  C.2  covers  the  steps  used  to  construct  the 
TRAPP-2  system  using  the  Base  System  Builder  in  Xilinx  Platform  Studio,  version 
11.4.  Section  C.3  details  the  required  software  modifications  in  the  hardware  files  to 
convert  the  Ethernet  controller  from  100  Mbps  (Media  Independent  Interface)  to  1000 
Mbps  (Reduced  Gigabit  Media  Independent  Interface  v2.0). 

C.l  Hardware  Description 

C.1.1  Microprocessor.  The  on-chip  PowerPC  440  processor  is  used  in  the 
TRAPP-2  system.  The  processor  executes  the  software  application. 

C.l. 2  Synchronous  Dynamic  Random  Access  Memory.  Two  512  MB  SDRAM 
modules  are  used  for  the  TRAPP-2  system.  The  first  module  is  formated  as  Xilinx 
Memory  File  System  to  temporarily  store  the  hash  file  before  the  hashes  are  trans¬ 
ferred  to  the  second  SDRAM  module.  The  second  module  does  not  have  a  file  system 
and  contains  the  actual  hashes  for  the  hash  list.  The  second  module  also  stores  the 
log  file  during  sniffing.  At  the  completion  of  sniffing,  the  log  file  is  transferred  to  the 
first  SDRAM  module  so  it  can  be  downloaded  from  the  FPGA  board. 

C.l. 3  Block  Random  Access  Memory.  For  this  implementation,  one  128- 
kilobyte  BRAM  is  used.  The  BRAM  block  contains  the  bootup  software  code,  data 
and  instruction  memory,  as  well  as  the  stack  and  heap. 

C.l. 4  XPS  Hard  Ethernet  Media  Access  Controller.  This  is  the  board’s 
Ethernet  connection.  The  Ethernet  controller  is  set  to  promiscuous  mode  to  receive 
all  packets  traversing  the  network.  The  Ethernet  controller  is  configured  as  a  RGMII 
v2.0,  capable  of  operating  at  1000  Mbps.  More  details  on  programing  the  Ethernet 
controller  to  operate  as  a  RGMII  interface  can  be  found  in  Section  G.3. 
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C.1.5  RS232  Universal  Asynchronous  Receiver/Transmitter.  The  RS232 
interface  serves  two  purposes.  The  hrst  is  to  output  general  information  about  board 
initialization  and  operational  status  as  well  as  detect  user  input  to  stop  sniffing.  The 
second  purpose  is  to  upload  hash  hies  to  the  board  and  download  the  Wireshark- 
compatible  log  hie.  This  is  accomplished  with  the  xmodem  protocol  through  the 
TeraTerm  Virtual  Terminal  program  [Ter09]. 

C.1.6  XPS  Timer.  The  timer  is  used  to  take  timestamps  for  calculating 
the  packet  processing  time,  measured  in  CPU  cycles.  Only  one  of  the  two  available 
timers  is  used. 

C.  2  Component  Configuration 

This  section  provides  a  step-by-step  guide  to  construct  the  TRAPP-2  system 
using  the  Base  System  Builder  in  Xilinx  Platform  Studio,  version  11.4. 

1.  To  begin  Open  Xilinx  Platform  Studio,  Click  on  File,  then  New  Project.  A 
window  will  appear  like  the  one  in  Figure  C.l. 


Figure  C.l:  The  Project  Creation  Options  Window. 


Ill 


2.  Name  the  project  file,  as  seen  in  Figure  C.2.  Click  “OK”  to  continue. 


Figure  C.2 


The  Project  Creation  and  Repository  Selection  Window. 
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3.  Select  the  “I  would  like  to  create  a  new  design”  radio  button  as  seen  in  Fig¬ 


ure  C.3.  Click  “Next”  to  continue. 


Figure  C.3:  The  Base  System  Builder  Design  Selection  Window. 
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4.  Select  the  “I  would  like  to  create  a  system  for  the  following  development  board” 
radio  button.  Choose  “Xilinx”  for  the  Board  Vendor,  “Virtex  5  ML510  Evalu¬ 
ation  Platform”  for  the  Board  Name,  and  “C”  for  the  Board  Revision,  as  seen 
in  Figure  C.4.  Click  “Next”  to  continue. 


Figure  C.4:  The  Board  Selection  Window. 
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5.  Select  the  “Single-Processor  System”  radio  button  as  seen  in  Figure  C.5.  Click 
“Next”  to  continue. 


Figure  C.5: 


The  Processor  Selection  Window. 
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6.  Select  the  “PowerPC”  for  the  Processor  Type,  “400.00”  for  Processor  Clock 
Frequency,  and  “100.00”  for  the  Bus  Clock  Frequency,  as  seen  in  Figure  C.6. 
Click  “Next”  to  continue. 


Figure  C.6:  The  Processor  Conhguration  Window. 
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7.  Add  the  following  peripherals,  ensuring  to  change  certain  options  (shown  in 
parenthesis)  from  the  dropdown  menus,  as  seen  in  Figure  C.7.  The  peripherals 
include: 


•  DDR2_SDRAM_DIMM0 

•  DDR2_SDRAM_DIMM1 

•  Hard_Ethernet_MAC 

•  RS232_Uart_l  (Set  Baud  Rate  to  115200) 

•  xps_bram_if_cntlr_0  (Set  Size  to  128  KB) 

•  xps_timer_0 

Click  “Next”  to  continue. 


Figure  C.7:  The  Peripheral  Conhguration  Window. 
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8.  Check  every  box  for  enabling  the  Data  and  Instruction  caches  for  the  processor, 


as  seen  in  Figure  C.8.  Click  “Next”  to  continue. 


Figure  C.8:  The  Processor  Cache  Conhguration  Window. 
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9.  The  Memory  and  Peripheral  Test  Applications  are  optional,  but  highly  recom¬ 
mended  to  ensure  the  board  is  functioning  properly.  Select  xps_bramJf_cntlr_0 
as  the  location  to  store  the  test  applications,  as  seen  in  Figure  C.9.  Click  “Next” 
to  continue. 


Figure  C.9:  The  Application  Selection  Window. 
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10.  This  window  summarizes  the  system  being  built,  as  seen  in  Figure  C.IO.  Click 


“Finish”  to  continue. 


Figure  C.IO:  The  Summary  Conhguration  Window. 
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11.  After  completing  the  Base  System  Builder,  a  window  pops  up  asking  about 
additional  configuration  settings.  Select  the  “Conhgure  drivers  and  libraries 
(Software  Platform)”  radio  button,  as  seen  in  Figure  C.ll.  Click  “OK”  to 
continue. 


Figure  C.ll:  The  Conhgure  Libraries  and  Drivers  Window. 
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12.  Highlight  “Software  Platform”  in  the  left  side  column.  Place  a  check  in  the 


“xilmfs”  checkbox,  as  seen  in  Figure  C.12.  Click  “OK”  to  continue. 


Figure  C.12: 


The  Software  Platform  Settings  Window. 
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13.  Highlight  “OS  and  Lib  Conhguration”  in  the  left  side  column.  Change  the 
following  options:  numbytes  (100,000,000),  base.address  =  0x0  (this  is  the  base 
address  of  the  SDRAM  that  holds  the  Xilinx  Memory  File  System),  init_type 
(MFSINIT_NEW),  need.utils  (true),  as  seen  in  Figure  C.13.  Click  “OK”  to 
continue.  Ensure  these  values  are  accurately  reflected  in  the  .mss  hie. 


Figure  C.13:  The  Software  Platform  Settings  OS  and  Lib  Conhguration  Window. 
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C.3  Converting  from  Mil  to  RGMII  v2.0 

This  section  details  the  software  modihcations  in  the  hardware  hies  to  convert 
the  Ethernet  controller  from  100  Mbps  (Mil)  to  1000  Mbps  (RGMII  v2.0). 


1.  Conhgure  HARD_ETHERNET_MAC  IP 

C_NUM_IDELAYCTRL=1 
C_IDELAYCTRL_L0C=N0T_SET 
Physical  Interface  Type  =  RGMII  V2.0 
RX  FIFO  Depth  of  TEMACO  =  32768B 

2.  In  the  .mhs  hie,  make  the  following  modihcations. 

Remove  all  Mil*  from  external  ports  and  add  the  following  lines: 


PORT  Hard_Ethernet_MAC_RGMII_TXD_0_pin  =  Hard_Ethernet_MAC_RGMII_TXD_0,  DIR  =  0,  VEC  =  [3:0] 
PORT  Hard_Ethernet_MAC_RGMII_TXC_0_pin  =  Hard_Ethernet_MAC_RGMII_TXC_0,  DIR  =  0 
PORT  Hard_Ethernet_MAC_RGMII_TX_CTL_0_pin  =  Hard_Ethernet_MAC_RGMII_TX_CTL_0 ,  DIR  =  0 
PORT  Hard_Ethernet_MAC_RGMII_RXD_0_pin  =  Hard_Ethernet_MAC_RGMII_RXD_0,  DIR  =  I,  VEC  =  [3:0] 
PORT  Hard_Ethernet_MAC_RGMII_RX_CTL_0_pin  =  Hard_Ethernet_MAC_RGMII_RX_CTL_0 ,  DIR  =  I 
PORT  Hard_Ethernet_MAC_RGMII_RXC_0_pin  =  Hard_Ethernet_MAC_RGMII_RXC_0,  DIR  =  I 

In  the  xpsJLtemac  section  of  the  .mhs  hie,  PORT  REPCLK  must  be  connected 
to  a  200MHz  clock.  The  name  may  be  diherent  between  designs. 

Add: 


PORT  GTX_CLK_0  =  clk_125mhz 

PORT  REFCLK  =  cIk_200_0000MHzPLL0 

PORT  RGMII_RXD_0  =  Hard_Ethernet_MAC_RGMII_RXD_0 

PORT  RGMII_RX_CTL_0  =  Hard_Ethernet_MAC_RGMII_RX_CTL_0 

PORT  RGMII_RXC_0  =  Hard_Ethernet_MAC_RGMII_RXC_0 

PORT  RGMII_TXC_0  =  Hard_Ethernet_MAC_RGMII_TXC_0 

PORT  RGMII_TX_CTL_0  =  Hard_Ethernet_MAC_RGMII_TX_CTL_0 

PORT  RGMII_TXD_0  =  Hard_Ethernet_MAC_RGMII_TXD_0 

In  the  clock_generator  section,  a  125MHz  clock  must  be  added.  The  number 
of  the  clock  depends  on  the  number  of  other  clocks  in  your  design.  Since  four 
clocks  already  existed,  the  new  one  is  C_CLKOUT5. 
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Add: 


PARAMETER  C_CLK0UT5_FREQ  =  125000000 
PARAMETER  C_CLK0UT5_PHASE  =  0 
PARAMETER  C_CLK0UT5_GR0UP  =  NONE 
PARAMETER  C_CLK0UT5_BUF  =  TRUE 
PORT  CLK0UT5  =  clk_125mhz 

3.  In  the  .ucf  file,  make  the  following  modihcations. 


Remove: 


Net  fpga_0_Hard_Ethernet_MAC_MII_TXD_0_piii<3>  LDC=AN31 
I  DRIVE  =  6; 

Net  fpga_0_Hard_Ethernet_MAC_MII_TXD_0_piii<2>  L0C=AR32 
I  DRIVE  =  6; 

Net  fpga_0_Hard_Ethernet_MAC_MII_TXD_0_piii<l>  L0C=AP32 
I  DRIVE  =  6; 

Net  fpga_0_Hard_Ethernet_MAC_MII_TXD_0_piii<0>  LDC=AR33 
I  DRIVE  =  6; 

Net  fpga_0_Hard_Ethernet_MAC_MII_TX_EN_0_pin  L0C=AP31  I 
I  DRIVE  =  6; 

Net  fpga_0_Hard_Ethernet_MAC_MII_TX_ER_0_pin  L0C=AT31  I 
I  DRIVE  =  6; 

Net  fpga_0_Hard_Ethernet_MAC_MII_RXD_0_piii<3>  L0C=AM33 
Net  fpga_0_Hard_Ethernet_MAC_MII_RXD_0_piii<2>  LDC=AK33 
Net  fpga_0_Hard_Ethernet_MAC_MII_RXD_0_piii<l>  L0C=AJ33 
Net  fpga_0_Hard_Ethernet_MAC_MII_RXD_0_piii<0>  L0C=AJ32 
Net  fpga_0_Hard_Ethernet_MAC_MII_RX_DV_0_pin  L0C=AN33 
Net  fpga_0_Hard_Ethernet_MAC_MII_RX_ER_0_pin  L0C=AP33 
Net  fpga_0_Hard_Ethernet_MAC_MII_RX_CLK_0_pln  L0C=J17 
Net  fpga_0_Hard_Ethernet_MAC_MII_TX_CLK_0_pln  L0C=M26 

Add: 


I  lOSTANDARD  =  LVCM0S25  I  SLEW  =  FAST 

I  lOSTANDARD  =  LVCMDS25  I  SLEW  =  FAST 

I  lOSTANDARD  =  LVCMDS25  I  SLEW  =  FAST 

I  lOSTANDARD  =  LVCM0S25  I  SLEW  =  FAST 

lOSTANDARD  =  LVCM0S25  I  SLEW  =  FAST 

lOSTANDARD  =  LVCM0S25  I  SLEW  =  FAST 

I  lOSTANDARD  =  LVCM0S25; 

I  lOSTANDARD  =  LVCM0S25; 

I  lOSTANDARD  =  LVCM0S25; 

I  lOSTANDARD  =  LVCM0S25; 

I  lOSTANDARD  =  LVCMDS25; 

I  lOSTANDARD  =  LVCMDS25; 

I  lOSTANDARD  =  LVCMDS25; 

I  lOSTANDARD  =  LVCMDS25; 


Net  Hard_Ethernet_MAC_RGMII_TXD_0_piii<3>  LOG 
I  DRIVE  =  24; 

Net  Hard_Ethernet_MAC_RGMII_TXD_0_piii<2>  LOG 
I  DRIVE  =  24; 

Net  Hard_Ethernet_MAC_RGMII_TXD_0_piii<l>  LOG 
I  DRIVE  =  24; 

Net  Hard_Ethernet_MAC_RGMII_TXD_0_piii<0>  LOG 
I  DRIVE  =  24; 

Net  Hard_Ethernet_MAG_RGMII_TX_GTL_0_pln  LOG 


=  AN31  1 

I0STANDARD=LVGMDS25 

1  SLEW=FAST 

=  AR32  1 

I0STANDARD=LVGMDS25 

1  SLEW=FAST 

=  AP32  1 

IDSTANDARD=LVGMDS25 

1  SLEW=FAST 

=  AR33  1 

I0STANDARD=LVGMDS25 

1  SLEW=FAST 

=  AP31  1 

I0STANDARD=LVGMDS25 

1  SLEW=FAST 
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I  DRIVE  =  24; 

Net  Hard_Ethernet_MAC_RGMII_TXC_0_piii  LOG  =  AM31  I  lOSTANDARD  =LVCMQS25  I  SLEW  =  FAST 
I  DRIVE  =  6; 


Net  Hard_Ethernet_MAC_RGMII_RXD_0_piii<3>  LOG  = 
Net  Hard_Ethernet_MAC_RGMII_RXD_0_piii<2>  LOG  = 
Net  Hard_Ethernet_MAC_RGMII_RXD_0_piii<l>  LOG  = 
Net  Hard_Ethernet_MAC_RGMII_RXD_0_piii<0>  LOG  = 
Net  Hard_Ethernet_MAC_RGMII_RX_GTL_0_pln  LOG  = 
Net  Hard_Ethernet_MAC_RGMII_RXC_0_piii  L0G=J17 


AM33 

AK33 

AJ33 

AJ32 

AN33 


I0STANDARD=LVGMDS25 ; 
IDSTANDARD=LVGMDS25 ; 
I0STANDARD=LVGMDS25 ; 
I0STANDARD=LVGMDS25 ; 
I0STANDARD=LVGM0S25 ; 


I0STANDARD=LVGMDS25 ; 


Remove: 


######  Hard_Etheriiet_MAC 

NET  "*Hard_Ethernet_MAG/LliiikTeniacO_GLK*"  TNM_NET  =  "LLGLKO" ; 

#naine  of  signal  connected  to  TEMAG  LIinkTemacO_GLK  input 
NET  "*Hard_Ethernet_MAG/SPLB_Glk*"  TNM_NET  =  "PLBCLK" ; 

#name  of  signal  connected  to  TEMAG  SPLB_GIk  input 

#  EMAGO  TX  Client  Clock 

NET  "*Hard_Ethernet_MAC/TxCIientCIk_0"  TNM_NET  =  "clk_client_tx0" ; 

TIMEGRP  "mii_client_clk_tx0"  =  "clk_client_tx0" ; 

TIMESPEC  "TS_inii_cIient_clk_txO"  =  PERIOD  "inii_client_clk_tx0" 

7500  ps  HIGH  50 

#  EMAGO  RX  Client  Clock 

NET  "*Hard_Ethernet_MAC/RxCIientCIk_0"  TNM_NET  =  "clk_client_rx0" ; 

TIMEGRP  "mii_client_clk_rx0"  =  "clk_client_rx0" ; 

TIMESPEC  "TS_giiiii_cIient_cIk_rxO"  =  PERIOD  "gmii_client_clk_rx0"  7500  ps  HIGH  50 

#  EMAGO  RX  PHY  Clock 

NET  "*Hard_Ethernet_MAC/MII_RX_CLK_0*"  TNM_NET  =  "phy_clk_rx0" ; 

TIMEGRP  "mii_clk_phy_rxO"  =  "phy_clk_rx0" ; 

TIMESPEC  "TS_inii_cIk_phy_rxO"  =  PERIOD  "inii_clk_phy_rx0"  40000  ps  HIGH  50 

#  EMAGO  TX  Mil  10/100  PHY  Clock 

NET  "*Hard_Ethernet_MAC/MII_TX_CLK_0*"  TNM_NET  =  "clk_mii_tx_clk0" ; 

TIMESPEC  "TS_inii_tx_clk0"  =  PERIOD  "clk_inii_tx_clkO"  40000  ps  HIGH  50  7.; 

#  Mil  Receiver  Constraints:  place  flip-flops  in  lOB 

INST  "*miiO*RXD_TO_MAC*"  lOB  =  TRUE; 

INST  "*miiO*RX_DV_TO_MAC"  lOB  =  TRUE; 

INST  "*miiO*RX_ER_TO_MAC"  lOB  =  TRUE; 

#  PHY  spec:  10ns  setup  time,  lOns  hold  time 

#  Assumes  equal  length  board  traces 

NET  "fpga_0_Hard_Ethernet_MAC_MII_RXD_0_pin(?)"  TNM  =  "mii_rx_0"; 

NET  "fpga_0_Hard_Ethernet_MAC_MII_RX_DV_0_pin"  TNM  =  "mii_rx_0"; 

NET  "fpga_0_Hard_Ethernet_MAC_MII_RX_ER_0_pin"  TNM  =  "mii_rx_0"; 

TIMEGRP  "mii_rx_0"  OFFSET  =  IN  10  ns  VALID  20  ns  BEFORE 
"fpga_0_Hard_Ethernet_MAC_MII_RX_CLK_0_pin" ; 

#  Mil  Transmiter  Constraints:  place  flip-flops  in  lOB 

INST  "*miiO*MII_TXD_?"  lOB  =  TRUE; 

INST  "*miiO*MII_TX_EN"  lOB  =  TRUE; 

INST  "*miiO*MII_TX_ER"  lOB  =  TRUE; 

TIMESPEC  TS_PLB_2_TXPHY0  =  FROM  PLBCLK  TO  clk_phy_txO  40000  ps  DATAPATHONLY ;  #constant 
value  based  on  Ethernet  clock 

TIMESPEC  TS_RXPHY0_2_PLB  =  FROM  phy_clk_rx0  TO  PLBCLK  10000  ps  DATAPATHONLY;  #varies 
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based  on  period  of  PLB  clock 


TIMESPEC  "TS_LL_CLK0_2_RX_CLIENT_CLK0"  =  FROM  LLCLKO  TO  clk_client_rxO  8000  ps 
DATAPATHONLY ;  #constant  value  based  on  Ethernet  clock 
TIMESPEC  "TS_LL_CLK0_2_TX_CLIENT_CLK0"  =  FROM  LLCLKO  TO  clk_client_txO  8000  ps 
DATAPATHONLY;  #constant  value  based  on  Ethernet  clock 
TIMESPEC  "TS_RX_CLIENT_CLK0_2_LL_CLK0"  =  FROM  clk_client_rxO  TO  LLCLKO  10000  ps 
DATAPATHONLY;  #varies  based  on  period  of  LocalLink  clock 
TIMESPEC  "TS_TX_CLIENT_CLK0_2_LL_CLK0"  =  FROM  clk_client_tx0  TO  LLCLKO  10000  ps 
DATAPATHONLY;  #varies  based  on  period  of  LocalLink  clock 

net  "*/hrst*"  TIG; 


Add: 


######  Hard_Ethernet_MAC 

#  EMACO  TX  Client  Clock 

NET  "*/RGMIl_TX_CTL_0*"  TNM_NET  =  "clk_client_txO" ; 

TIMEGRP  "rginii_client_clk_txO"  =  "clk_client_txO" ; 

TIMESPEC  "TS_rgmii_client_clk_txO"  =  PERIOD  "rgniii_client_clk_txO"  7800  ps  HIGH  50 

#  EMACO  RX  Client  Clock 

NET  "*/RGMII_RX_CTL_0*"  TNM_NET  =  "clk_client_rxO" ; 

TIMEGRP  "rginii_client_clk_rxO"  =  "clk_client_rxO" ; 

TIMESPEC  "TS_rgniii_client_clk_rxO"  =  PERIOD  "rgniii_client_clk_rxO"  7800  ps  HIGH  50 

#  EMACO  TX  PHY  Clock 

NET  "*/RGMII_TXC_0*"  TNM_NET  =  "clk_phy_txO" ; 

TIMEGRP  "rginii_phy_clk_txO"  =  "clk_phy_txO" ; 

TIMESPEC  "TS_rgmii_phy_clk_txO"  =  PERIOD  "rgmii_phy_clk_txO"  7800  ps  HIGH  50 

#  EMACO  RX  PHY  Clock 

NET  "*/RGMII_RXC_0"  TNM_NET  =  "clk_phy_rxO" ; 

TIMEGRP  "rginii_clk_phy_rxO"  =  "clk_phy_rxO" ; 

TIMESPEC  "TS_rgmii_clk_phy_rxO"  =  PERIOD  "rgmii_clk_phy_rxO"  7800  ps  HIGH  50 


#  Set  the  IDELAY  values  on  the  data  inputs. 

#  Please  modify  to  suit  your  design. 


INST 
INST 
INST 
INST 
INST 
INST 
INST 
INST 
INST 
INST 
INST 
INST 
NET 
TIMESPEC 
TIMESPEC 
TIMESPEC 
TIMESPEC 


*rgmiiO?rgmii_rx_ctl_delay' 

*rgmiiO?rgmii_rx_dO_delay" 

*rgmiiO?rgmii_rx_dl_delay" 

*rgmil0?rgmii_rx_d2_delay" 

*rgmii0?rgmii_rx_d3_delay" 


lOBDELAY.TYPE  =  FIXED; 
IOBDELAY_TYPE  =  FIXED; 
IOBDELAY_TYPE  =  FIXED 
IOBDELAY_TYPE  =  FIXED 
IOBDELAY_TYPE  =  FIXED 


"*rgmii_rxc0_delay"  IOBDELAY_TYPE  =  FIXED; 
"*rgmiiO?rgmii_rx_ctI_delay"  IDELAY_VALUE  =  25; 
"*rgmilO?rgmii_rx_dO_delay"  IDELAY_VALUE  =  25; 
"*rgmiiO?rgmii_rx_dl_delay"  IDELAY_VALUE  =  25 
"*rgmii0?rgmii_rx_d2_delay"  IDELAY_VALUE  =  25 
"*rgmii0?rgmii_rx_d3_delay"  IDELAY_VALUE  =  25 
"*rgmii_rxc0_delay"  IDELAY_VALUE  =  0; 
*/LlinkTemacO_CLK*"  TNM_NET  =  "LLCLK"; 

TS_LL_CLK0_2_RX_CLIENT_CLK0"  =  FROM  LLCLKO  TO 
TS_LL_CLK0_2_TX_CLIENT_CLK0 
TS_RX_CLIENT_CLK0_2_LL_CLK0 
TS_TX_CLIENT_CLK0_2_LL_CLK0 


clk_client_rxO  8000  ps 
=  FROM  LLCLKO  TO  clk_client_txO  8000  ps 
=  FROM  clk_client_rx0  TO  LLCLKO  8000  ps 
=  FROM  clk_client_tx0  TO  LLCLKO  8000  ps 


DATAPATHONLY 

DATAPATHONLY 

DATAPATHONLY 

DATAPATHONLY 
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